[FYI][all] PySnooper, a poor man's debugger
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 ;)
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 :) [1] https://github.com/cool-RR/pysnooper
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.
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.
On Mon, 2019-04-22 at 11:51 -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.
yep i agree :) i started programming on windows so i have alway had good grapical debugger avaiable so when i started working on openstack the fact that eventlets breaks debugging used to kill me so i got to be more ok with print/log debbuging as i often had to fight with it less. recently eventlets is less of an issue as gevent support was developed by the pycharm folks in there debugger. that said i when i need to debug more involved code i do still pull out pycharm vs code. having a handy decorator that i can use when im coding in nano/emacs is also nice to have in my tool box. as i dont always want to have to install an ide in a vm i create to test a random thing.
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.
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 :)
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
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
participants (5)
-
Artom Lifshitz
-
Ben Nemec
-
Bernard Cafarelli
-
Sean Mooney
-
Slawek Kaplonski