Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Icecream: Never use print() to debug again in Python

github.com

Post reply on HN
Print view View original

61–70 of 271 posts

Re: Icecream: Never use print() to debug again in Python

#61

Post by Hnrobert42 »

mikkelam wrote: post #12

Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster and just plainly worse in all aspects. Especially in Pycharm for me, it is incredibly easy. Even when running over ssh in remote computers I can use my debugger.

Debuggers are great. But to unboggle your mind, here’s why I don’t use a Python debugger.

I don’t write enough Python to justify the time to learn the debugger. I write just enough to help my staff/teammate fix their problem or debug some tool I’m using and move on.

I’ve been doing this long enough to lose interest in digging deeply into each language. I learned gdb for C. After that I learned jdb and Eclipse for Java. There was probably something I used for the few years I wrote PERl later PHP. After a while I stopped getting excited about deeply learning new languages and their tools.

Debuggers and IDEs are yet another dependency. Frequently I use systems I don’t control, like client systems. They have really stringent rules about what can be installed. The lowest common denominator is vim and print.

Certainly there are lots of reasons to learn debuggers. But there are also lots of valid reasons to learn a tool like this which is easy to learn, useful in across many languages, and gets the job done in many situations.

Re: Icecream: Never use print() to debug again in Python

#62

Post by zestyping »

nneonneo wrote: post #8

For an even easier-to-remember alternative, there’s q: https://github.com/zestyping/q All you need is `import q`. q works like a function (q(x)), like a variable (q|x and q/x, so you get different operator precedences) and like a decorator (@q), so it can be used in practically any circumstance for a quick debug print. Plus, the name sounds like you’re interrogating something.

I was wondering whether someone would notice that it's a clone of q! Thanks! :)

q has the additional feature that you can decorate any function or method with `@q`, which causes invocations to be logged with arguments, return values, and exceptions. Really handy for tracing what's happening in your program.

Re: Icecream: Never use print() to debug again in Python

#63

Post by fouc »

tamentis wrote: post #33
atoav wrote: post #6

I am sorry, but I am not going to pull in an external dependency just for this, especially not with the power of fstrings in newer python versions.

You're just being difficult. It's easy, you just setup these 10 Node.js micro services in docker, setup your database, the cache. Then my friend, you can really debug with beautiful print messages. Wait until someone creates a $10/user SaaS service out of it.

Insightful prediction of how development will be done in the future.

Re: Icecream: Never use print() to debug again in Python

#64

Post by zestyping »

mikkelam wrote: post #12

Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster and just plainly worse in all aspects. Especially in Pycharm for me, it is incredibly easy. Even when running over ssh in remote computers I can use my debugger.

It depends on the situation.

In general, debuggers give you much more contextual information, but using a debugger is extremely slow. To see what's going on, you have to step through your program, one line at a time, until the interesting thing happens. That can take ages.

If you want to see how a specific function is behaving and it's called 100 times, it's a lot easier to look at a printed log of the 100 calls and scan or search it for interesting behaviour than to pause the program in a debugger and step through it over and over, hoping to catch the interesting moment.

Re: Icecream: Never use print() to debug again in Python

#65

Post by pletnes »

masklinn wrote: post #40
ninjin wrote: post #29

Earlier quoted context omitted.

Thank you, I was unaware of this. While I have lost a talking point in favour of Julia – the `@show` macro – I am happy that my old friends over in Python land has access to some better ergonomics and can stop rubbing this in their face. ;) julia> x = 4711 4711 julia> @show x x = 4711 4711

I don't know what `@show` does exactly, but Python's is only a limited convenience for print, it still not as good as Rust's dbg![0] or TFA's ic, because it does not (and can not) return its parameter unmodified, so you still need to inject an explicit print and possibly execute the expression multiple times. It's convenient, don't get me wrong, but it's not exactly groundsbreaking. Unlike breakpoint[1]. [0] https://…

Do you have any concrete usage examples of that? I’ve only used breakpoint() to stop execution while debugging.

Re: Icecream: Never use print() to debug again in Python

#66

Post by est »

kissgyorgy wrote: post #5

You can do the same thing with Python 3.8+ by using f-strings and just appending "=" to the variable name: >>> print(f"{d['key'][1]=}") d['key'][1]='one'

You can also use the breakpoint() introduced in py3.7 via PEP533

https://www.python.org/dev/peps/pep-0553/

Re: Icecream: Never use print() to debug again in Python

#67

Post by mixmastamyk »

zestyping wrote: post #64
mikkelam wrote: post #12

Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster and just plainly worse in all aspects. Especially in Pycharm for me, it is incredibly easy. Even when running over ssh in remote computers I can use my debugger.

It depends on the situation. In general, debuggers give you much more contextual information, but using a debugger is extremely slow. To see what's going on, you have to step through your program, one line at a time, until the interesting thing happens. That can take ages. If you want to see how a specific function is behaving and it's called 100 times, it's a lot easier to look at a printed log of the 100 calls and…

Yes, and sometimes I hit the wrong key and have to start again.

Re: Icecream: Never use print() to debug again in Python

#69

Post by mixmastamyk »

enriquto wrote: post #35
mikkelam wrote: post #12

Why don't people just use a debugger? It boggles my mind that people live with print style debugging. Depending on the project, it can be such a timer waster and just plainly worse in all aspects. Especially in Pycharm for me, it is incredibly easy. Even when running over ssh in remote computers I can use my debugger.

> Why don't people just use a debugger? I only speak for myself, but I find that time spent inside a debugger is "lost", and bound to be re-spent again and again if you ever find new problems with the same code. I pretty much prefer to add assertions, logging and comments to my program, that will stay there and make further re-reads easier and more useful. As a matter of principle, I never use a debugger (except for…

Agreed, and tests too.

Re: Icecream: Never use print() to debug again in Python

#70

Post by sammorrowdrums »

pletnes wrote: post #65
masklinn wrote: post #40

Earlier quoted context omitted.

I don't know what `@show` does exactly, but Python's is only a limited convenience for print, it still not as good as Rust's dbg![0] or TFA's ic, because it does not (and can not) return its parameter unmodified, so you still need to inject an explicit print and possibly execute the expression multiple times. It's convenient, don't get me wrong, but it's not exactly groundsbreaking. Unlike breakpoint[1]. [0] https://…

Do you have any concrete usage examples of that? I’ve only used breakpoint() to stop execution while debugging.

In the docs you can look up breakpoint, it has a lot of features amongst other things you can register a custom handler. I use it in selenium tests so I can either debug on error or just print the error message and continue
Post reply on HN