Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PySnooper: Never use print for debugging again

github.com

Post reply on HN
Print view View original

151–160 of 175 posts

Re: PySnooper: Never use print for debugging again

#151

Post by chaitanya »

yingw787 wrote: post #98
chaitanya wrote: post #41

Is there an equivalent of Common Lisp's TRACE in the Python world? IMO it is the most value for money (i.e. time and convenience) debugging tool I've used till now. Simply write (TRACE function1 function2 ...) in the REPL and you will get a nicely formatted output of arguments passed and value(s) returned for each invocation of the given functions. Another nice feature is that a deeper an invocation is in the stack t…

I use this snippet: ``` import ipdb ipdb.set_trace() ``` It drops me into IPython, an interactive Python shell, with the interactive Python debugger. You can type variables and use `pdb` primitives like (c)ontinue, (u)p call stack, (n)ext line, etc. I really like it, but ofc YMMV.

Yeah but the idea is that, with TRACE, most of the time you shouldn't need to drop into the debugger (all CLs come with an interactive debugger too). If TRACE is not sufficient, only then do I go down the debugger route (or strategic print statements).

Re: PySnooper: Never use print for debugging again

#152

Post by chaitanya »

meken wrote: post #136
chaitanya wrote: post #41

Is there an equivalent of Common Lisp's TRACE in the Python world? IMO it is the most value for money (i.e. time and convenience) debugging tool I've used till now. Simply write (TRACE function1 function2 ...) in the REPL and you will get a nicely formatted output of arguments passed and value(s) returned for each invocation of the given functions. Another nice feature is that a deeper an invocation is in the stack t…

%xmode in ipython does something similar, but only when an exception is hit. https://ipython.readthedocs.io/en/stable/interactive/magics....

Nice. Does CPython have something like this?

Re: PySnooper: Never use print for debugging again

#153

Post by vaylian »

That looks really nice! I normally use pudb which is a curses-based debugger but pudb falls short when the debugged program runs with several threads or if it uses an asynchronous event loop. Having a non-interactive debugger like PySnooper could definitely help in such situations!

Re: PySnooper: Never use print for debugging again

#154

Post by kurtisc »

Gibbon1 wrote: post #91
rossdavidh wrote: post #65

While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a print statement is just fine, and anything else is overabstracting it. Not saying other options aren't nice to have available, just that there is nothing wrong with using a simple print statement in many situations.

Because the observability you get with a print statement is limited. You can't do further investigation without modifying the code and running it again. With a debugger you can explore the program state interactively. My experience with python is limited but in my day job it's not uncommon to be tracking down stuff that happens infrequently. Debug cycles get brutally long.

You also can't be confident that a debugged program is in a natural state without restarting it, at which point the re-setting of the breakpoints and scripting you did in the last invocation - or saving and loading what you've already done - is a pain point. If all of this is quicker than recompiling/relaunching, then IMO there is a second bug in a lack of effective logging.

Most bugs I create are for simple reasons and can be found by scanning the first error logs. If I add print statement debugging because I couldn't then they'll often be adapted into additional logging. If I use a debugger for this as my first tool and don't add logs, I'll have to do it again next time, too[1].

If the bug is not a simple one and is not a structural bug, there's a decent chance it's something debuggers deal with poorly: data races, program boundaries, non-determinism, memory errors. If it's something that can be found by calling a function with certain parameters, it's a missing test case.

So the times I find debuggers to be worth it are after I've already decided it's a difficult yet uncommon bug. So I use them with despair.

[1] If I fix it with a debugger and then add the logs, I still have to prove it gives the right output when it fails.

Re: PySnooper: Never use print for debugging again

#155

Post by kurtisc »

rossdavidh wrote: post #65

While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a print statement is just fine, and anything else is overabstracting it. Not saying other options aren't nice to have available, just that there is nothing wrong with using a simple print statement in many situations.

I agree. Print is the most fundamental tool available to you: debuggers are kernel and hardware spanning monsters that introduce an external logic dependency. We don't advocate for more complexity than is necessary in other places.

Re: PySnooper: Never use print for debugging again

#157

Post by maximleon »

Dont think it works, tried few examples, it throws NotImplementedError at me all the time. Any hint?

~/anaconda3/lib/python3.7/site-packages/pysnooper/tracer.py in get_source_from_frame(frame) 75 pass 76 if source is None: ---> 77 raise NotImplementedError 78 79 # If we just read the source from a file, or if the loader did not

NotImplementedError:

Re: PySnooper: Never use print for debugging again

#159

Post by oblio »

_jal wrote: post #69
craftyguy wrote: post #67

Earlier quoted context omitted.

Once you go down the path, it's easy to start adding more and more, and it's easy to forget about them. They sometimes blend in well with patches you generate, since it's just a 'print()' and nothing obvious like 'import pdb; pdb.set_trace()'

That's a matter of being organized and competent, not a fault of print(). People create bugs by forgetting things all the time. If you believe their spin, FB snarfed millions of contact lists by accident because of that. I've troubleshot countless things that happened because of code that fell between the cracks. And on the other side of that, I could tell you about the time we went a month without logs in production…

> That's a matter of being organized and competent, not a fault of print().

Or you can be organized and competent at a higher level and just use tools. We're using computers for a reason :)

Re: PySnooper: Never use print for debugging again

#160

Post by scbrg »

oblio wrote: post #158
lsh wrote: post #141

Earlier quoted context omitted.

honestly, fuck the whole standard logging library in Python. It is the most infuriating thing to use. log4j has a lot to answer for

Why?

    >>> import logging
    >>> logging.info('Hello, world!')
    >>> # right, my log message went nowhere
Because by default, logging goes nowhere. And if you configure logging - using a most unintuitive config format (it's so weird that even the documentation about it can't be bothered to use it, but reverts to yaml to explain what it means!) - there's a good chance that loggers created before you got around to configure it (for instance if you, God forbid, made the mistake of adhering to PEP-8 and sticking your import statements at the top) won't use your configuration - and thus send their log messages, again, nowhere.

Also, it's slow as hell.

Post reply on HN