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

91–100 of 175 posts

Re: PySnooper: Never use print for debugging again

#91

Post by Gibbon1 »

rossdavidh wrote: post #65

While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a print statement is just fine, and anything else is overabstracting it. Not saying other options aren't nice to have available, just that there is nothing wrong with using a simple print statement in many situations.

Because the observability you get with a print statement is limited. You can't do further investigation without modifying the code and running it again. With a debugger you can explore the program state interactively.

My experience with python is limited but in my day job it's not uncommon to be tracking down stuff that happens infrequently. Debug cycles get brutally long.

Re: PySnooper: Never use print for debugging again

#92

Post by Gibbon1 »

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.

Classic in C is to use a define to enable/disable print statements.

   //#DEBUG 1
   #include "debug.h"

Re: PySnooper: Never use print for debugging again

#93

Post by OrgNet »

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…

With python being a language that tries to only have one way of doing each thing, maybe they should have figured that out at the beginning stages of the language's design phase.

Re: PySnooper: Never use print for debugging again

#96

Post by ben509 »

josteink wrote: post #85

> You'd love to use a full-fledged debugger with breakpoints and watches, but you can't be bothered to set one up right now. In VSCode: built in. Press the play icon. In Emacs: M-x realgud:pdb Is that really more effort than this? Why invent inferior solutions to solved problems?

Installation for a module like this:

    cd project
    pip install pysnooper  # or pipenv or poetry
And it works.

That's far superior to poking around in the dark trying to make an IDE see my project correctly.

If IDE authors ever figure out how to implement a test button that invokes `python -c "some stuff"` and shows me the results, I'd consider using them.

Re: PySnooper: Never use print for debugging again

#97

Post by josteink »

ben509 wrote: post #96
josteink wrote: post #85

> You'd love to use a full-fledged debugger with breakpoints and watches, but you can't be bothered to set one up right now. In VSCode: built in. Press the play icon. In Emacs: M-x realgud:pdb Is that really more effort than this? Why invent inferior solutions to solved problems?

Installation for a module like this: cd project pip install pysnooper # or pipenv or poetry And it works. That's far superior to poking around in the dark trying to make an IDE see my project correctly. If IDE authors ever figure out how to implement a test button that invokes `python -c "some stuff"` and shows me the results, I'd consider using them.

> If IDE authors ever figure out how to implement a test button that invokes `python -c "some stuff"`

You mean like both Emacs and VSCode already does?

Re: PySnooper: Never use print for debugging again

#98

Post by yingw787 »

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.

Re: PySnooper: Never use print for debugging again

#99

Post by alexisnorman »

johnernaut wrote: post #37
digitalsushi wrote: post #32

As a very mediocre ruby programmer, is there an equivalent in ruby to this? If you have a little pattern that is more clever than 'puts' everywhere, please share, it would be well received by at least one person out there. Thanks!

Yes, check out Pry: https://pryrepl.org/

Second that, pry rules!

Re: PySnooper: Never use print for debugging again

#100

Post by wang_li »

eganist wrote: post #89
wang_li wrote: post #87

Earlier quoted context omitted.

Citing professionalism isn't a quip, it's shorthand for a code of conduct and long accepted practices of interaction with others. May I ask how the word "shitty" more truthful than "poorly written" or "complex"?

> May I ask how the word "shitty" more truthful than "poorly written" or "complex"? Evokes emotions people affected by a situation can sympathize with more effectively, which by virtue of establishing a shared emotional bond over a topic helps the developer convey not just the situation but the frustrations of the situation more effectively than one might expect "poorly written" or "complex" to do alone. > Citing pro…

> exhibition of professionalism from yourself to the OP to build a sound defense of your position

It's well understood that some words are offensive to some people. Just like I wouldn't advertise my utility as being exceptionally useful in a nigger-rigged or woman written code base, I don't see any advantage to using shitty over poorly written or complex. I recognize that I'm using terms that are a lot more inflammatory, I am trying to illustrate the point with an easily understood example. You might not care about shitty, someone else may not care about nigger-rigged, and someone else may care about both. Since the idea can be expressed without offending any of the group, why offend unnecessarily?

> where the audience by-and-large may not care.

Objectively the audience does care. Otherwise the initial comment would never have been made. We all can let it roll off our backs, but it does affect the author's image among his potential user base.

Post reply on HN