Live data from Hacker News

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

github.com

201–210 of 271 posts

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

#201

Earlier quoted context omitted.

How is changing code simpler than literally clicking on the line number to set a breakpoint?

You said "click", I need to leave my keyboard. Generally when I am coding I auto-run the tests on save. This means that to printf-debug I just add a message or two (and if I am coding I might already have a couple of useful ones lying around) and save. Then in less than a second I have a trace trough my program in the terminal. If I want to inspect a different variable I just add another print and run again. With a d…

You said "click", I need to leave my keyboard.

Every proper IDE has a keyboard shortcut for that though.

With a debugger I need to kill my auto-run command, run the program, set breakpoints, type to see what variables I want to inspect

This indeed falls under your 'part of my problem is that because I rarely use a debugger' statement. E.g you could set breakpoints before you save, use auto-debug instead (i.e. launch program under the debugger on save instead of just rnning it - without breakpoints there shouldn't be much of a difference unless it's one of those nasty multithreading bugs), add variables you want to see to the watch window. Or type them anyway if it's a one-time thing. Or use tracepoints. Etc.

I personally keep bouncing back and forth between debugger and printing. All depends on context, but it's definitely worth it getting to know both really well.

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

#203

Earlier quoted context omitted.

How is changing code simpler than literally clicking on the line number to set a breakpoint?

Depending on how complex your debugger is, it allows you to output values that might not be inspectable through the debugger. Especially computed values. Debug printing also allows you to debug programs running in environments where you can't attach a debugger. For example, maybe halting the program causes the bug not to trigger. Or it's a remote system where you cannot attach a debugger for various reasons. Or the b…

Especially computed values

Showing function return values automatically was really an eye-opener when I first encountered it.

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

#204
post #80

I am always going to use print to debug in every programming language I can until the day I die.

The old style printf from C is still the best formatting tool for output/debugging. The C++ style was just a distraction without introducing anything of real value. log4xyz has some nice features in terms of enabling/disabling at runtime, through a config, but ultimately, printf rules.

The old style printf from C is still the best formatting tool for output/debugging.

The idea that you can just drop this anywhere, sure, that is good. But once you've used string interpolation printf isn't so attractive anymore. No more forgetting arguments, wrong argument order, wrong specifier, ...

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

#205
post #198

I started writing a very-alpha related tool, https://github.com/czinck/pyset_x . As the name implies, it's like `set -x` in bash, in that it prints every line as it executes. It's more useful for situations where you have some complicated control flow and it's not working exactly how you expect.

Funny, a few months back I added this sentence to PySnooper's readme: "PySnooper is a poor man's debugger. If you've used Bash, it's like set -x for Python, except it's fancier." https://github.com/cool-RR/PySnooper

I saw someone mention PySnooper elsewhere in this thread, I think if I had known it existed before I probably wouldn't have bothered with `pyset_x`.

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

#206

I used to teach people to use the amazing debuggers we have now so that they'd never have to use print statements to debug their code. Since I became a front-end developer, all I've done is use print statements to debug JS. Feels like I've gone backwards.

Why don't you use the devtools debugger? I generally find people in webdev tend to use debuggers more than other fields because it's so readily available in devtools, or with `debugger` in JavaScript.

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

#208

I promise the 15 minutes it takes to learn to use the debugger will save years of your life

The issue is that the debugger stops execution at the breakpoint, but most often I want to analyze multiple print statements together. The debugger and repl have their uses, but IMHO I am usually better served by adding a print and having the script automatically re-run itself.

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

#209
post #60

Earlier quoted context omitted.

Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.

How is changing code simpler than literally clicking on the line number to set a breakpoint?

You have to first configure your IDE/editor to allow you debugging. This is different for every programming language/environment. Print works in any language without prior configuration.

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

#210
post #82

Earlier quoted context omitted.

For Python: ipdb. In your code, you can just drop in "import ipdb; ipdb.set_trace()" and the execution will stop there with an interactive prompt. Alternatively start the script through (i)pdb and set breakpoints. You can also use plain pdb ("import pdb; pdb.set_trace()"), which has the advantage that it comes with the Python stdlib, but the interactive prompt is less fancy (no history, no autocompletion, etc).

Add `export PYTHONBREAKPOINT=ipdb.set_trace` to your .bashrc and "breakpoint()" will invoke ipdb by default.

That is a great trick, thank you!
Post reply on HN