PySnooper: Never use print for debugging again
1–10 of 175 posts
Re: PySnooper: Never use print for debugging again
#2This looks pretty useful. I love these packages that seem like forgotten stdlib features.
Re: PySnooper: Never use print for debugging again
#3that gonna be huge chunk of log to search
Re: PySnooper: Never use print for debugging again
#4that 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.
Re: PySnooper: Never use print for debugging again
#5Interesting 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
Re: PySnooper: Never use print for debugging again
#6Interesting 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)pdb is built in and is simple to use
pdb and its variants (my favorite is PuDB) are generally difficult to use in complex, corporate projects. If you've got a multi-process, multi-thread Python project running on a remote host, you'll need a really full-featured debugger to work with it effectively. I recommend Wing IDE or PyCharm for that.
Re: PySnooper: Never use print for debugging again
#7Will it work with multiprocessing?
Re: PySnooper: Never use print for debugging again
#8Interesting 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.
Re: PySnooper: Never use print for debugging again
#9Will 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
Re: PySnooper: Never use print for debugging again
#10Interesting 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
It isn't always that easy. For example, where I work, bringing up a full stack locally involves multiple Python processes (servers) with the frontend accessed via the browser.
Using this tool will work immediately, while using pdb would be a bother (comparatively).