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