Live data from Hacker News

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

github.com

231–240 of 271 posts

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

#231
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.

I think it's a (confusing) two-layer pun. When read phonetically as letter names, the name "ic" sounds like "I see". "ic" also is an initialism for "ice cream". Everyone loves ice cream, and so another low-meaning cutesy-poo pun-ishment of a name was born. I think. Pure speculation here.

Bingo.

All the one letter PyPi project names were taken.

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

#233

> prints both its own arguments and the values of those arguments. That's not enough. Almost always I also want the argument type . Occasionally a unique (i.e. as precise as possible) sortable (i.e. with leading zeros) time stamp also comes useful.

This would be great to have.

I don't use types in my Python much. Yet at least.

Can you submit a PR to add this? That'd be awesome.

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

#234
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://…

What is TFA?

icecream, the subject of this post, returns its parameter unmodified without multiple evaluations.

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

#235

I use PySnooper[1] when code behavior deviates inscrutably from my mental model. Like Icecream, PySnooper exhorts, "Never use print for debugging again." A simple example: import pysnooper @pysnooper.snoop() def add_up(numbers): total = 0 for number in numbers: total += number return total add_up([123, 456]) When run, PySnooper prints the activity of the decorated function or method: $ python example.py Source path:.…

There's also https://github.com/alexmojaki/snoop

For comparison:

    19:32:30.66 >>> Call to add_up in File "/home/joel/example.py", line 5
    19:32:30.66 ...... numbers = [123, 456]
    19:32:30.66 ...... len(numbers) = 2
    19:32:30.66    5 | def add_up(numbers):
    19:32:30.66    6 |     total = 0
    19:32:30.66    7 |     for number in numbers:
    19:32:30.66 .......... number = 123
    19:32:30.66    8 |         total += number
    19:32:30.66 .............. total = 123
    19:32:30.66    7 |     for number in numbers:
    19:32:30.66 .......... number = 456
    19:32:30.66    8 |         total += number
    19:32:30.66 .............. total = 579
    19:32:30.66    7 |     for number in numbers:
    19:32:30.66    9 |     return total
    19:32:30.66 

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

#237
post #151

Earlier quoted context omitted.

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 inadverte…

> Imagine how many times you need to click next

Once or twice? Any sane debugger has a way to disable the breakpoint.

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

#238

I use PySnooper[1] when code behavior deviates inscrutably from my mental model. Like Icecream, PySnooper exhorts, "Never use print for debugging again." A simple example: import pysnooper @pysnooper.snoop() def add_up(numbers): total = 0 for number in numbers: total += number return total add_up([123, 456]) When run, PySnooper prints the activity of the decorated function or method: $ python example.py Source path:.…

There's also https://github.com/alexmojaki/snoop For comparison: 19:32:30.66 >>> Call to add_up in File "/home/joel/example.py", line 5 19:32:30.66 ...... numbers = [123, 456] 19:32:30.66 ...... len(numbers) = 2 19:32:30.66 5 | def add_up(numbers): 19:32:30.66 6 | total = 0 19:32:30.66 7 | for number in numbers: 19:32:30.66 .......... number = 123 19:32:30.66 8 | total += number 19:32:30.66 .............. total = 123…

From the README, Snoop is "primarily meant to be a more featureful and refined version of PySnooper. It also includes its own version of icecream and some other nifty stuff."

Thanks. I'll give it a try.

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

#239
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.

It's for debugging. Not something to depend on in released code. Put the import in your site initialization file and you won't even have to import it in the REPL.

I understand, but Python >3.8 can do this:

  >>> x = 1+1
  >>> print(f"{x = }")
  x = 2
And if it is included why pulling in a dependency? And even if it is a dev dependency: it can be a dev dependency that bites you in two years in the middle of a night when your service fails.

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

#240
post #221

Earlier quoted context omitted.

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

When I use a debugger I often feel like I'm looking through a soda straw. I can only see the state at that one instance in time. Just because I know the line of code where the exception occurred, doesn't tell me which data caused it, and breaking on exceptions is often too late. Instead I'm stuck hitting continue over and over until I finally see something out of place, realize I went to far and have to start over ag…

I more or less agree; but I find myself wondering why I so often use Matlab's debugger, but almost never use pdb for python. It is not like I'm not used to using command line tools (I use bash, git, emacs, etc. everyday). It could just be an accident of habit, I don't know.
Post reply on HN