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

111–120 of 175 posts

Re: PySnooper: Never use print for debugging again

#111

Post by guitarbill »

jcroll wrote: post #79
guitarbill wrote: post #66

Earlier quoted context omitted.

There is pretty-print [0], which you could dump inside pre tags, or print to stdout. But honestly, depending on the framework, quicker options exist than (basically) printf debugging. [0] https://docs.python.org/3/library/pprint.html#example

For Flask what would be the better option?

Pretty much the stuff already mentioned elsewhere on HN for this article. I often find Werkzeug's excellent debugger is enough: https://news.ycombinator.com/item?id=19718869 . pdb/ipdb/pudb et al (pick your fav) can help for really tricky stuff. And sufficient logging, so you know what's going on at all times even without a debugger attached.

(occasionally, the low effort of print-debugging works, but if you keep having to print in more/different locations... it's a blunt tool IMO)

Re: PySnooper: Never use print for debugging again

#112

Post by BenFrantzDale »

strunz wrote: post #88
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 love using PDB, but even still this has a different use case. Say you have a bug in a function and it depends on timing or it's a race condition, or it has a lot of statements. Being able to see the state throughout the function in your output may be able to catch things or speed up debugging.

Agreed. My go-to for debugging is `import epdb;epdb.st()` which is a quick and dirty breakpoint. There may be more elegant solutions but that has served me very well.

Re: PySnooper: Never use print for debugging again

#114

Post by jasonhansel »

IMO the real advantage of print() over a full-fledged debugger comes when you're testing. Just replace print() calls with assert(). (Also debuggers, especially on the front end, always seem incredibly laggy and slow.)

Using debuggers tends to encourage people to fix problems without writing regression tests.

Honestly, I'd prefer "better support for print-line debugging" to "better debugger that you can set up" in most cases.

Re: PySnooper: Never use print for debugging again

#116

Post by JHer »

josteink wrote: post #84
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…

Yeah. Python is dead easy to debug via pdb. If you don’t want to go CLI-debugging both VSCode and Emacs have more integrated, in-editor options. Many bugs can be isolated and reproduced in unit-tests. That’s just a click away from being debuggable inside a real debugger. Why use anything but that? To me, not using a debugger to debug seems kinda crazy.

Debugging python processes running in containers unfortunately requires a bit of setup in VS Code (no idea about Emacs).

Re: PySnooper: Never use print for debugging again

#117

Post by thanatropism »

jcroll wrote: post #79
guitarbill wrote: post #66

Earlier quoted context omitted.

There is pretty-print [0], which you could dump inside pre tags, or print to stdout. But honestly, depending on the framework, quicker options exist than (basically) printf debugging. [0] https://docs.python.org/3/library/pprint.html#example

For Flask what would be the better option?

I try to have "debug calls" that I can call from the browser or Postman or Swagger, etc. and return all sorts of debug information, etc.

I have the impression that local program-specific debugging tools quickly evolve into something like functional tests that uncover issues that functional tests proper might not cover. For example, if I'm serving a ML model but I have a debug call that runs sanity checks on the data that are too expensive to run each time.

Re: PySnooper: Never use print for debugging again

#118

Post by askvictor »

strunz wrote: post #88
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 love using PDB, but even still this has a different use case. Say you have a bug in a function and it depends on timing or it's a race condition, or it has a lot of statements. Being able to see the state throughout the function in your output may be able to catch things or speed up debugging.

True, though pysnooper (and print statements for that matter) will change the execution speed, so won't necessarily catch timing bugs (or introduce new ones).

Re: PySnooper: Never use print for debugging again

#119

Post by Xavdidtheshadow »

iamgopal wrote: post #51
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-...

This is what I'm going to try to use in every language from now on.

Except for JS, which will execute `1/0` happily and without complaint. For that, I usually do `undefined.foo`.

Re: PySnooper: Never use print for debugging again

#120

Post by spc476 »

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've done something similar (but not exact) for Lua [1]. I was testing code to trace Lua execution and found some code that was executed more than I expected [2]. Adding a trace like you described should be easy as well in Lua.

[1] http://boston.conman.org/2015/02/12.1

[2] http://boston.conman.org/2015/02/13.1

Post reply on HN