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

141–150 of 175 posts

Re: PySnooper: Never use print for debugging again

#141

Post by lsh »

thatoneuser wrote: post #129
anitil wrote: post #128

Earlier quoted context omitted.

I've definitely had the experience of using custom_logger.log("something"), then checking the system log. Nope, no there, must be in /var/log/app ... nope. Hmm oh I know! I'll turn up the logging in the config file, wherever that is. Still nothing. Did I need to compile in some flag? Screw it. print, run directly from shell, done.

Fuck var/log/app.

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

Re: PySnooper: Never use print for debugging again

#143

Post by int_19h »

Gibbon1 wrote: post #132
cknd wrote: post #102

Earlier quoted context omitted.

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.

Crash dump debugging is tricky to implement Python, because its normal debugging APIs - sys.settrace, frame objects etc - require being inside the process with a running Python interpreter.

You can still do it, but you basically have to redo the whole thing from scratch. For example, instead of asking for a repr() of an object to display its value, you have to access the internal representation of it directly - and then accommodate all the differences in that between various Python versions. Something like this (note several different dicts): https://github.com/Microsoft/PTVS/tree/bcdfec4f211488e373fa2...

Re: PySnooper: Never use print for debugging again

#144

Post by scrollaway »

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…

If you're going to use print debugging I highly recommend the package "q". It's print debugging on steroids.

Always logs to /tmp/q no matter what stdout redirects the app has set up. Syntax highlighting. Context dumping. Dumps large values to separate files. Etc.

Re: PySnooper: Never use print for debugging again

#145

Post by craftyguy »

maw wrote: post #72
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()'

When the language I'm using permits it -- that is, when I'm not using Python -- I deliberately misindent them. They're very visible in diffs then. And even if accidentally committed they're still easy to spot and eliminate later.

That's nice and all, but we're kind of talking about Python here, which won't allow misindentation.

Re: PySnooper: Never use print for debugging again

#146

Post by yoz »

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…

Python's standard lib has had something like this for years, but it's been criminally under-promoted (probably because of the terrible name): https://docs.python.org/3/library/cgitb.html

However, yours provides much nicer output. Thank you!

Re: PySnooper: Never use print for debugging again

#147

Post by badatshipping »

int_19h wrote: post #140
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.co…

Oh wow, I never knew about that. Thanks.

Re: PySnooper: Never use print for debugging again

#148

Post by draven »

lsh wrote: post #142
butuzov wrote: post #34

Again, Ram - it's a really nice project. Good luck with it. But just in case if you from print cult, you will like https://github.com/gruns/icecream

"Ram"? I went looking for a project called Ram but couldn't find one. Link?

It's the author of the package, the readme says: Copyright (c) 2019 Ram Rachum, released under the MIT license.

Re: PySnooper: Never use print for debugging again

#149

Post by fulafel »

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…

There's sys.settrace(mytracefun), so something like https://stackoverflow.com/a/32607930

Re: PySnooper: Never use print for debugging again

#150

Post by chaitanya »

fulafel wrote: post #149
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…

There's sys.settrace(mytracefun), so something like https://stackoverflow.com/a/32607930

Thanks! Yeah this should do the trick I think.
Post reply on HN