On Mon, 22 Apr 2019 at 21:26, Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
Thanks. It looks really interesting :)
On Mon, Apr 22, 2019 at 11:51:49AM -0500, Ben Nemec wrote:
On 4/22/19 8:32 AM, Artom Lifshitz wrote:
tl;dr Instead of debugging with LOG.debug and/or print() statements all over the place, use the pysnooper decorator [1].
I came across this on Hacker News this morning - if you're like me and are too lazy to invest in learning a real debugger, and instead do it with LOG.debug/print()s all over the place, pysnooper might be useful to you. This line from the README feels particularly relevant to me ;)
I'm going to mildly object to the characterization of print and log debugging as "lazy". I've spent plenty of time in debuggers over the
years
and in many cases I just prefer a simple print over stepping through a huge number of lines of code. Both debugging techniques have their place and nobody should feel bad because they chose one over the other.
Exactly. Imagine debugging e.g. some race condition issue. Using simple prints may be much better in such case to find out what is going on wrong there :)
Which is exactly what I was looking for a few days ago, when trying to track down what could end in a (rare) test failure. It looks very interesting indeed, and seems to work fine on first tests!
What makes PySnooper stand out from all other code intelligence
tools?
You can use it in your sh***y, sprawling enterprise codebase without having to do any setup.
I tried it out with a random Nova unit test by decorating the function being tested, and it gave me the expected analysis of how the function executed.
Just sharing this, I hope it might be useful to someone :)
I've starred it. It looks a bit like bash's xtrace on steroids, which is something I use quite a lot when debugging bash scripts.
-- Slawek Kaplonski Senior software engineer Red Hat
-- Bernard Cafarelli