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

181–190 of 271 posts

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

#181

Post by tstrimple »

josalhor wrote: post #116
0xFFFE wrote: 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.

The same thing happens all over Software really. Just because a tool is powerful is looked up as superior, or better. The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion. I legitimately believe print debugging is incredibly powerful (With a simple print I can check if a function is being called, how many times, if the…

Print debugging has all of those features and is natively built into just about every programming language in existence and doesn’t require any additional libraries or tools.

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

#183

Post by wrycoder »

altitudinous wrote: post #4

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

“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.”

— Brian Kernighan, “Unix for Beginners” (1979)

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

#184

Post by Macha »

sebastialonso wrote: post #169
Macha wrote: post #151

Earlier quoted context omitted.

Imagine putting breakpoints in multiple tight loops in the stage of narrowing the search space. Imagine how many times you need to click next. A conditional breakpoint will only help if you know the condition you're looking for, but there's stage before that of "Well, what looks strange during execution". Also for multithreaded code, stopping one thread dead for long enough for a human to investigate it can inadverte…

What I imagine Macha is arguing for is that the cost of using print is extremely small, smaller at least than breakpoints. No one is saying breakpoints are useless, sometimes printing is 'cheaper' in time and effort in order to locate the region code of code in which using breakpoints is cheaper.

Yes, print() and breakpoints are different tools with different uses and there's cases where one is superior to the other. This is why some tools now offer logpoints, which are basically print() inserted via a breakpoint UI rather than in your code where you can forget to remove them

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

#185

Post by Merad »

offtop5 wrote: post #161

It should take a competent programmer about 30 minutes to create a nice log class with more flexibility for their particular application. On one hand thank you for sharing, on the other hand if I add this to my project at work my boss is going to scold me

I don't do much Python, but logging is a problem that's been thoroughly solved in just about every other language I've used. Why on earth would you reach for a half baked homemade solution?

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

#188

Post by klibertp »

gwenzek wrote: post #168
klibertp wrote: post #113

Earlier quoted context omitted.

> you have to step through your program, one line at a time You can set more than one breakpoint at a time. Hitting 'c' will get you to the next breakpoint, no matter where it is. > and step through it over and over No, you don't (shouldn't) do that. You write a conditional breakpoint which activates when something interesting happens.

OTOH if you're able to write `if bug_will_happen_on_next_line(): breakpoint()` you're pretty much done debugging.

No, when starting debugging you most often know the results of a bug. You can break conditionally on when the results appear, then work your way up the stack or jump to the beginning of a block to re-examine it. Or you can rerun the program, this time with a breakpoint set based on the inspection of the environment when the bug happened.

In pdb not only can you set breakpoints with conditions[1], you can also assign commands to be executed when the breakpoint is reached[2]. You can also use `display` command to - effectively - insert temporary `print`s in any stack frame[3]. Coupled with `up`, `down`, and `jump` commands, and the ability to evaluate any code in the scope of a break, it really gives you a lot of options on how to find the problem.

Though, logging is still a good thing. When I see a commented out `print` in code review, I usually suggest to replace it with a DEBUG level logger call. Extensive logging does help to trace the execution, it can be disabled when not needed, and can improve the readability of the code. Although raw print is an antipattern (can't easily enable some and disable other, need to clean up after debugging, doesn't display the stack trace, etc.), logging is a valid technique which complements the usage of a debugger nicely.

[1] https://docs.python.org/3/library/pdb.html#pdbcommand-break

[2] https://docs.python.org/3/library/pdb.html#pdbcommand-comman...

[3] https://docs.python.org/3/library/pdb.html#pdbcommand-displa...

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

#189

Post by xeyownt »

sltkr wrote: post #97
jerzyt wrote: post #80

Earlier quoted context omitted.

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 value introduced by C++ was type safety. In C, it's way too easy for the format string to get out of sync with the type of the arguments, e.g.: printf("%d", my_long_var); Might seem correct and work correctly on one platform, but fail on another. scanf() is arguably even worse since it can cause memory corruption. These days compilers have diagnostics to catch those errors, but if you rely on those you can't use…

Maybe C++ fixed type safety, but it introduced lot of complexity and bugs for no actual added value. For instance, because of stateful ios objects, it's close to impossible to write correct code outputing hex on first attempt. I'm sure that lot of C++ code outputing hex is just plain wrong.

Given that C++ keeps getting more and more complex features, it is just amazing that C++ I/O is still so inconvenient, opaque and ultra-verbose.

Post reply on HN