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

101–110 of 175 posts

Re: PySnooper: Never use print for debugging again

#101

Post by jmuhlich »

yingw787 wrote: post #98
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 use this snippet: ``` import ipdb ipdb.set_trace() ``` It drops me into IPython, an interactive Python shell, with the interactive Python debugger. You can type variables and use `pdb` primitives like (c)ontinue, (u)p call stack, (n)ext line, etc. I really like it, but ofc YMMV.

Try pdb++ (pdbpp) instead — it's like a much improved ipdb. It monkeypatches itself into pdb rather than defining a new package, so it works from any context that drops into the debugger. Its “sticky mode” alone is worth the switch.

Re: PySnooper: Never use print for debugging again

#102

Post by cknd »

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 context and local variables [i], sort of a souped up version of the built-in crash message. It's surprising how much that already helped in a few situations, makes me wonder why it isn't the default.

So, yes, more debuggers, but also abundant logging everywhere!

[i] https://github.com/cknd/stackprinter

Re: PySnooper: Never use print for debugging again

#103

Post by nitrogen »

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…

Also someone should make a debugger that supports the equivalent of print statements, e.g. set print breakpoint on a variable to print its value every time it’s run, instead of typing print everywhere.

Traditonal debuggers like gdb for compiled languages support this (breakpoint actions, memory write breakpoints, and variable displays). If something similar isn't already in your language's debugger, that might be a source of ideas for adding it.

Re: PySnooper: Never use print for debugging again

#104

Post by StavrosK »

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

This is great, thanks! I've been wanting this from the q library for ages, but the author hasn't responded in a few years. I'll switch to this right away, thanks again!

Re: PySnooper: Never use print for debugging again

#105

Post by bkyan »

mikepurvis wrote: post #63
bkyan wrote: post #55

Have you considered providing an option to pipe the output to a Slack channel or something similar to that?

Unsure if serious, but if you're looking for a crash reporter tool that integrates with Slack, you might be interested in something more like Sentry.

Yes, I was serious. I'm curious why you thought I was joking? cool-RR thought I was joking, as well, so I must be missing something... ¯\_(ツ)_/¯ Thanks for the tip on Sentry -- I'll take a look!

Re: PySnooper: Never use print for debugging again

#107

Post by scbrg »

stefano wrote: post #61
apetresc wrote: post #48

Earlier quoted context omitted.

But this isn't a debugger. It's just instrumenting a function with some very verbose logs.

But it's harder to install this, import it, and add a decorator than it is to type "breakpoint()".

It might be easier than migrating to 3.7, and then typing "breakpoint()"

Re: PySnooper: Never use print for debugging again

#110

Post by mikepurvis »

bkyan wrote: post #105
mikepurvis wrote: post #63

Earlier quoted context omitted.

Unsure if serious, but if you're looking for a crash reporter tool that integrates with Slack, you might be interested in something more like Sentry.

Yes, I was serious. I'm curious why you thought I was joking? cool-RR thought I was joking, as well, so I must be missing something... ¯\_(ツ)_/¯ Thanks for the tip on Sentry -- I'll take a look!

Oh, just that "chat ops" is one of those goofy fads that seemed to flare up everywhere and burn itself out really quickly, so any mention of it immediately triggers my satire meter.

Quite apart from that, the tool described looks like something you'd use in an intensive debugging session, so it's hard for me to imagine how it would fit in with an alerting workflow.

Post reply on HN