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

11–20 of 175 posts

Re: PySnooper: Never use print for debugging again

#11

Post by cool-RR »

whitehouse3 wrote: post #8
scaryclam wrote: post #5

Interesting project, though I'd suggest losing the line about "can't be bothered to set one up right now" regarding a full debugger. (i)pdb is built in and is simple to use. Perhaps focus on what this can add rather than framing the project as something like a lazy alternative (especially when this may actually be harder to set up than throwing in "import pdb; pdb.set_trace()")? edit: spelling

I’d also lose the profanity. > You can use it in your shitty, sprawling enterprise codebase without having to do any setup. Debugging is a sensitive subject, particularly given how frustrating it can be. There’s a place for vulgarity somewhere, but I’d rather see your README provide authoritative info than crack jokes.

I wrote a lot of shitty, sprawling enterprise code over the years, and I feel there's no shame in admitting that's what it is :)

Re: PySnooper: Never use print for debugging again

#12

Post by tgbugs »

I have to say sometimes I do find it much easier to read logs than to muck about in an interactive interpreter. That said I did just add `export PYTHONBREAKPOINT=pudb.set_trace` to my bashrc and am slowly going through and removing all my old `from IPython import embed` lines. A much simpler workflow that doesn't incur major runtime costs.

Re: PySnooper: Never use print for debugging again

#13

Post by sametmax »

cool-RR wrote: post #9
fifnir wrote: post #7

Will it work with multiprocessing?

Good question. If the function is launched in a spawned process, it'll work, though you might have trouble getting the stderr, so you better include a log file as the first argument, like this `@snoop('/var/log/snoop.log')` If the function launches new processes internally... I'm not sure. If you try it and it doesn't work, open an issue: https://github.com/cool-RR/PySnooper/issues

There is a race condition when writting on the same log file from several processes at the same time, which is a typical use case for wsgi frameworks such as django or flask.

Re: PySnooper: Never use print for debugging again

#14

Post by cool-RR »

tgbugs wrote: post #12

I have to say sometimes I do find it much easier to read logs than to muck about in an interactive interpreter. That said I did just add `export PYTHONBREAKPOINT=pudb.set_trace` to my bashrc and am slowly going through and removing all my old `from IPython import embed` lines. A much simpler workflow that doesn't incur major runtime costs.

PuDB is amazing. Best command-line debugger ever, plus you get feelings of nostalgia for the Borland days.

Re: PySnooper: Never use print for debugging again

#15

Post by hguhghuff »

scaryclam wrote: post #5

Interesting project, though I'd suggest losing the line about "can't be bothered to set one up right now" regarding a full debugger. (i)pdb is built in and is simple to use. Perhaps focus on what this can add rather than framing the project as something like a lazy alternative (especially when this may actually be harder to set up than throwing in "import pdb; pdb.set_trace()")? edit: spelling

On the contrary I think the author is spot on. I can never be bothered to get the debugger going no matter how easy.

Re: PySnooper: Never use print for debugging again

#16

Post by sametmax »

cool-RR wrote: post #4
v3ss0n wrote: post #3

that gonna be huge chunk of log to search

No, because by default it only logs what's happening directly in your function, not what happens deeper in the stack. (i.e. functions that your function calls.) You can set depth=2 or depth=3 and then you'll get a huge chunk of log. The deeper levels will be indented.

Does it have an option to print the caller ? "u" is my fav cmd in pdb.

Re: PySnooper: Never use print for debugging again

#17

Post by cool-RR »

sametmax wrote: post #16
cool-RR wrote: post #4

Earlier quoted context omitted.

No, because by default it only logs what's happening directly in your function, not what happens deeper in the stack. (i.e. functions that your function calls.) You can set depth=2 or depth=3 and then you'll get a huge chunk of log. The deeper levels will be indented.

Does it have an option to print the caller ? "u" is my fav cmd in pdb.

No, feel free to add it as feature request on GitHub.

Re: PySnooper: Never use print for debugging again

#19

Post by cool-RR »

hguhghuff wrote: post #18

I love this concept and will definitely be using it. Presumably it works with Django? If yes then thrice thanks. This project would justify an additional dedicated screen just for dumping function debug logs.

I confirmed it worked with Django before releasing :)

Re: PySnooper: Never use print for debugging again

#20

Post by detaro »

sametmax wrote: post #13
cool-RR wrote: post #9

Earlier quoted context omitted.

Good question. If the function is launched in a spawned process, it'll work, though you might have trouble getting the stderr, so you better include a log file as the first argument, like this `@snoop('/var/log/snoop.log')` If the function launches new processes internally... I'm not sure. If you try it and it doesn't work, open an issue: https://github.com/cool-RR/PySnooper/issues

There is a race condition when writting on the same log file from several processes at the same time, which is a typical use case for wsgi frameworks such as django or flask.

Seems like a "log to this unix domain socket" option could help for those cases? Or one to open a new file for new PIDs?
Post reply on HN