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

241–250 of 271 posts

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

#241

Post by the_cat_kittles »

dbrgn wrote: post #82
atakan_gurkan wrote: post #68

Earlier quoted context omitted.

Which debugger would you recommend?

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).

i use this frequently! but print() is still handy and my go to

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

#242

Post by P_I_Staker »

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.

Depending on the use case it can be a sign that they don't understand how to debug efficiently. Not that this is something you should judge someone for.

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

#244

Post by _false »

alexmojaki wrote: post #235
jshprentz wrote: post #170

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…

Just what I was looking for, thanks

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

#245

Post by Fethbita »

Macha wrote: post #151
maccard wrote: post #140

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…

Today I was trying to solve the exact scenario in the second example. A multi threaded program had a race condition that would sometimes occur. printing numbers helped a great deal. Might also be that I'm not that proficient with my debugger even though I use that more than anything.

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

#246

Post by matheusmoreira »

pavon wrote: post #221
purerandomness wrote: post #112

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…

Would be nice if instead of break points debuggers had log points which stored the values of variables at that point in time. This data can be displayed as a table later.

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

#247

Post by roca »

pavon wrote: post #221
purerandomness wrote: post #112

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…

You might be interested in Pernosco: see https://pernos.co/about/overview/ and its related content.

We agree with your critique of traditional debuggers and Pernosco tackles that "temporal visibility" problem head on.

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

#248

Post by Noumenon72 »

josalhor wrote: post #119
nneonneo wrote: post #8

For an even easier-to-remember alternative, there’s q: https://github.com/zestyping/q All you need is `import q`. q works like a function (q(x)), like a variable (q|x and q/x, so you get different operator precedences) and like a decorator (@q), so it can be used in practically any circumstance for a quick debug print. Plus, the name sounds like you’re interrogating something.

This is actually really cool. I was going to say that so many people miss the point of print debugging and as a consequence forget to shorten the import line as much as possible. from icecream import ic;ic() is 28 characters import q;q() is 12 characters print() is 7 characters

The article says you can call

    from icecream import install
    install()
in main, and from then on icecream counts as a built-in, so you can just say ic(). Four characters.

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

#249

Post by angrais »

josalhor wrote: post #147
oauea wrote: post #136

Earlier quoted context omitted.

Why would the amount of characters possibly matter?

I find it important because it lowers the barrier of entry to print debugging. I have found myself using less prints in Java than in Python both because of static typing and having to write the full `System.out.println`. This is also important to me because I am very cautious of not doing a file-level import (I don't want to commit a file with the dependency). The fewer characters it takes, the easier it is for me to…

Do you use typing in Python?

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

#250

Post by JetAlone »

willyt wrote: post #149
JetAlone wrote: post #13

Earlier quoted context omitted.

In this case, it would seem it took a little reinvention in order to let the wheel's discovery be known.

Not used it, but ic seems to be compatible back to python 2.7 so not really comparable. I can't use the builtin thing in my python code because the host software for my plugins is running python 3.6 embedded and only recently upgraded from 3.3 in the latest release so if I want to maintain backwards compatibility I can never use the new python builtin. I expect lots of other people are in the same position.

Yeah you're right. I hadn't realized it was so new till a little later... Well, it's good that IC has a stronger use case surface area for those who want it.
Post reply on HN