Live data from Hacker News

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

github.com

251–260 of 271 posts

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

#251
post #225

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'

Hey! I'm Ansgar. I wrote Icecream. f-strings's `=` is awesome . I'm overjoyed it was added to Python. I use it all the time. That said, IceCream does bring more to the table, like: - Stynax highlighting. - Pretty prints data structures. - Returns its value for nesting. - Integrates with logging via `ic.configureOutput()`. etc I hope that helps!

Thank you for writing IceCream! I've used it off and on over the years and it's been a great help.

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

#252
post #66

Earlier quoted context omitted.

You can also use the breakpoint() introduced in py3.7 via PEP533 https://www.python.org/dev/peps/pep-0553/

Pre 'breakpoint()' you could always use import pdb; pdb.set_trace() That said, sometimes you don't want to interrupt execution and see your results in real time.

I like `from IPython import embed; embed()` because you get an entire ipython instance with access to all local variables :)

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

#253

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

I had this exact thought, but the title gives the wrong impression (at least to me). The package just defines a fancy print.

Sure, but typing ic(someVariable) is a lot faster for me than typing print(f"{someVariable=}") in Python3.8 or >, and still faster than typing print(f"someVariable={someVariable}") in Python It's especially faster when I think about how often I fat-finger the '{' (and '}', when my editor doesn't insert the matching brace automagically). Of course YMMV.

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

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

And I am going to use it, because of the pain of typing {, which half the time my fingers miss (whereas I'm pretty good at typing 'i' and 'c').

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

#255
post #225

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'

Hey! I'm Ansgar. I wrote Icecream. f-strings's `=` is awesome . I'm overjoyed it was added to Python. I use it all the time. That said, IceCream does bring more to the table, like: - Stynax highlighting. - Pretty prints data structures. - Returns its value for nesting. - Integrates with logging via `ic.configureOutput()`. etc I hope that helps!

I just got my first serving of icecream, thanks to the post here. And I'm a convert.

One question: in most cases, I get an output like `ic| tmp.py:9 in nonesuch() at 03:23:52.479` What is the "at 03:23:52.479", and how do I turn it off? Looks like it's some sort of timer function, but I don't see it in the readme. Python3.7 on Linux.

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

#256

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

What is TFA? icecream, the subject of this post, returns its parameter unmodified without multiple evaluations.

> What is TFA?

The fine article

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

That would be my point, yes.

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

#260
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…

> Imagine how many times you need to click next Once or twice? Any sane debugger has a way to disable the breakpoint.

Then you overshoot the iteration that has a problem
Post reply on HN