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

131–140 of 175 posts

Re: PySnooper: Never use print for debugging again

#131

Post by marcell »

scwoodal wrote: post #43

For my Django projects the development server is werkzeug [1] and anywhere a break point is needed I'll add 1/0 in the code then hit refresh in the browser which pulls up an interactive debugger [2]. [1] https://django-extensions.readthedocs.io/en/latest/runserver... [2] https://werkzeug.palletsprojects.com/en/0.15.x/debug/#using-...

FYI you can do

    import pdb; pdb.set_trace()
It pulls up console debugger and is a standard python package.

Re: PySnooper: Never use print for debugging again

#132

Post by Gibbon1 »

cknd wrote: post #102
badatshipping wrote: post #83

This is a thoughtful hack but the real solution here is a) make debuggers easier to set up and b) make your project easily debuggable with a debugger from the beginning. Like, debugging should be considered part of programming, and a local dev environment that can’t be debugged should be viewed to be as broken as a codebase without e.g. a way to run the server in watch mode. Also someone should make a debugger that s…

One situation where I would have wanted a real debugger and couldn't use one was in crash reporting on remote systems (like, machine learning code running in some container somewhere, or on a headless box far from the network). Since Python's built-in tracebacks are pretty minimal, the default crash logs don't offer much help other than a line number. I ended up writing a tool that prints tracebacks along with code c…

Old school neckbeard way

a) Crashes dump the program state to a file and then you load that in the debugger.

b) If the process is still running but broken, attach the debugger.

c) In my firmware I log bus fault addresses and restart. That allows me to see what code or memory access caused the error. 75% of the time it's fairly obvious what happened.

Re: PySnooper: Never use print for debugging again

#133

Post by Rapzid »

yason wrote: post #75

Happy to see new tools for debugging. Yet it's the good old print that I most often end up using. Debugging is very context-sensitive: adding prints makes sense because I know exactly what I'm interested in, and I can drill down on that without being disturbed by anything else. I can print low-level stuff or high-level indicators, depending where my debugging takes me. There's no ready-made recipe for that. Some code…

Log points are awesome. Like break points but they add print/log. First seen in nodejs via vscode; not sure if python has anything like it. Can even attach to remote running process and add them.

Re: PySnooper: Never use print for debugging again

#134

Post by scwoodal »

marcell wrote: post #131
scwoodal wrote: post #43

For my Django projects the development server is werkzeug [1] and anywhere a break point is needed I'll add 1/0 in the code then hit refresh in the browser which pulls up an interactive debugger [2]. [1] https://django-extensions.readthedocs.io/en/latest/runserver... [2] https://werkzeug.palletsprojects.com/en/0.15.x/debug/#using-...

FYI you can do import pdb; pdb.set_trace() It pulls up console debugger and is a standard python package.

The visual of the entire traceback in the browser and the ability to drop into an interactive shell within a specific frame is (for me) a way better experience than pdb.

Re: PySnooper: Never use print for debugging again

#135

Post by euske »

Never use print for debugging again... If you're creating a reasonably complex project, spend some time to set up a nice and robust logging facility and always use it instead of print. That's the first thing you should do. You will not regret that decision.

I sometimes use a debugger to tackle with unfamiliar code, but I always prefer using trace/logging whenever possible, because 1) you can see the context and whole process that reached that point, and 2) the history of debugging can be checked into a VCS. I'd write an one-liner to scan the log file rather than setting up a conditional breakpoint. I particularly like doing this for a GUI application. A regression testing can be done by comparing logs.

Re: PySnooper: Never use print for debugging again

#136

Post by meken »

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....

Re: PySnooper: Never use print for debugging again

#137

Post by int_19h »

Rapzid wrote: post #133
yason wrote: post #75

Happy to see new tools for debugging. Yet it's the good old print that I most often end up using. Debugging is very context-sensitive: adding prints makes sense because I know exactly what I'm interested in, and I can drill down on that without being disturbed by anything else. I can print low-level stuff or high-level indicators, depending where my debugging takes me. There's no ready-made recipe for that. Some code…

Log points are awesome. Like break points but they add print/log. First seen in nodejs via vscode; not sure if python has anything like it. Can even attach to remote running process and add them.

Python extension for VSCode supports logpoints.

In general, something like this has been around in IDEs for a very long time - e.g. Visual Studio proper added them back in 2005, except it calls them "tracepoints".

Re: PySnooper: Never use print for debugging again

#139

Post by int_19h »

scwoodal wrote: post #43

For my Django projects the development server is werkzeug [1] and anywhere a break point is needed I'll add 1/0 in the code then hit refresh in the browser which pulls up an interactive debugger [2]. [1] https://django-extensions.readthedocs.io/en/latest/runserver... [2] https://werkzeug.palletsprojects.com/en/0.15.x/debug/#using-...

I wonder if they support breakpoint() ?

https://docs.python.org/3/library/functions.html#breakpoint

Re: PySnooper: Never use print for debugging again

#140

Post by int_19h »

badatshipping wrote: post #83

This is a thoughtful hack but the real solution here is a) make debuggers easier to set up and b) make your project easily debuggable with a debugger from the beginning. Like, debugging should be considered part of programming, and a local dev environment that can’t be debugged should be viewed to be as broken as a codebase without e.g. a way to run the server in watch mode. Also someone should make a debugger that s…

I'm not sure what you mean by "debugger equivalent of print statements".

If what you want is a breakpoint that just prints something out when it's hit, then these already exist, e.g.:

https://code.visualstudio.com/docs/editor/debugging#_logpoin...

But "set breakpoint on a variable" kinda sounds more like a data breakpoint (i.e. break/log when value changes)? These also exist in some places:

https://docs.microsoft.com/en-us/visualstudio/debugger/using...

but usually with many limitations. The problem with these is that it's hard to implement it in such a way that there's zero overhead when not debugging. If I remember correctly, native data breakpoints have some hardware support on Intel, but for high-level languages it can be difficult to map their data model to something like that.

Post reply on HN