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

151–160 of 271 posts

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

#151

Post by Macha »

maccard wrote: post #140
ZaoLahma wrote: post #114

Earlier quoted context omitted.

Sometimes sticking the debugger into the wheel makes stuff come flying over the handle bars in spectacular ways that have nothing to do with what you wish to observe. You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. In these cases prints work well as a less intrusive way to get a rough idea of what is going on.

I don't understand your wheel analogy, sorry. > You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. If you don't know where to put a breakpoint, how do you know where to put a print statement?

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 inadvertently resolve all sorts of race conditions.

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

#152

Post by vlovich123 »

taneq wrote: post #130
vonwoodson wrote: post #115

Earlier quoted context omitted.

Bump. This is the most correct way to debug python programs VS using print statement.

Debugging virtually anything real-time that interacts with other systems will require some kind of logging (of which printf() is the trivial case). Step-through debugging is great but far from universally applicable.

Setting a breakpoint that prints and continues is appropriate if performance doesn’t matter. It gets trickier if it does. In those cases RR seems like the best idea rather than prints. At least that’s the theory.

In my experience the conditions on the ground are different though. Tooling availability is inconsistent, which is why such approaches don’t always work. Reverse debugging isn’t available on all platforms/languages. Debuggers (or at least the C/C++ ones) are slow in how they inject instrumentation code to evaluate - rather than compiling expressions into native codes to conditionally trap, they seem to trap unconditionally and evaluate the conditional using their introspection language (there are valid reasons why it’s done this way but it has serious performance impacts). In compiled languages, the evaluation of the expression can be difficult/impossible to write because of this (not enough type information available, validation is late binding meaning mistakes are extra expensive, etc.

At the end of the day, when your tools fail you, print debugging is easier to use to accomplish the task rather. Getting tooling to work effectively is more time consuming and frequently not possible.

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

#153

Post by Igelau »

mybrid wrote: post #127

The only thing I will say is that this would not meet my personal code review standards for logging. Rule number one is never put functional calls in a logging statement, only log static data. As optimistic as one might be that the 'ic' has no side effects, the most conservative approach is to never put anything that interacts with run-time behavior in a log statement. This is especially good practice when working in…

It says on the tin that it's for print debugging. That's not the same as logging.

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

#154

Post by wadkar »

amelius wrote: post #103
mkl wrote: post #88

Earlier quoted context omitted.

You can also make it a bit prettier by adding spaces: >>> print(f"{d['key'][1] = }") d['key'][1] = 'one' It works with any expression you like, not just variables: >>> print(f'{np.sin(np.pi/4.) = }') np.sin(np.pi/4.) = 0.7071067811865475

> It works with any expression you like Also assignment expressions? :)

I believe the walrus operator `:=` was introduced in Python 3.8. So keep that it in mind.

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

#157

Post by Igelau »

robsws wrote: post #104

This looks cool and all, but why is it called Icecream? I know naming abstract stuff is hard but it feels like this lends itself to a more descriptive name. "ic()" tells me nothing about what the function does.

At its core, it has always called inspect.currentframe(). I suspect the first iteration was a wrapper around inspect.currentframe(), abbreviated as ic(), which was then backronym'd into ice cream.

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

#158

Post by andix »

0xFFFE wrote: post #60
altitudinous wrote: post #4

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

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.

Because you shouldn’t have to change code, just to debug it.

It’s okay though to add verbose logging as a feature.

But just adding some print statements to debug code and remove them afterwards, is dangerous (you release sth different than you debugged).

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

#160

Post by Consultant32452 »

andix wrote: post #158
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.

Because you shouldn’t have to change code, just to debug it. It’s okay though to add verbose logging as a feature. But just adding some print statements to debug code and remove them afterwards, is dangerous (you release sth different than you debugged).

############################# What? #########################
Post reply on HN