I used to do print debugging a lot. And then I tried using the `breakpoint()` call available since Python 3.7[1], and now I can't imagine doing any serious debugging without PDB (or any other debugger).

(I mentioned Python, since this is linking to the Python-flavor of Icecream).

Sure, there are still times when just calling print() is sufficient. But they are becoming less frequent. `print()` is only shorter than `breakpoint()` by just 5 - len(variable_name_to_print) characters after all.

I know `import pdb; pdb.set_trace()` was available before, though `breakpoint()` is just a lot simpler, among others for the reasons they mentioned in the PEP.

There is also the `--pdb` flag in pytest[2], that lets me jump into a PDB session upon test failure.

All of this makes me think, what are the cases where print-level debugging is the better option in Python, compared to using an actual debugger?

[1] https://www.python.org/dev/peps/pep-0553/

[2] https://docs.pytest.org/en/latest/usage.html#using-the-built...

And if you really spend a lot of time in a python debugger, pudb (https://pypi.org/project/pudb/) is a lot of fun. It includes a full curses debugger, it saves breakpoints between runs, can run any interpreter (ipython, bpython, ...) you want, etc.

And since it's console only, you can even run it remotely without too much hassle.

If you're at a tty, PuDB is the best. For everything else, there's icecream.

    (defmacro ic (expr)
      `(prog2
         (format t "~&ic| ~A: " ',expr)
         (prin1 ,expr)
         (terpri)))

This is a lisp macro that (1) ensures the debug statement is printed on a newline, (2) prints the expression that got evaluated in its originally read form, (3) prints the value readably, (4) prints a newline, (5) return EXPR. Conforms to ANSI Common Lisp. Works on all implementations. No cute logo or testing required.

If you want to inspect execution, interrupt it, resume it, look at the call stack, look at local variables, then you can use Lisp’s function called break. No external tool required. No installing a dependency or debugger. Works on all implementations.

    (break "stop right there!")

Cute.

As you can see from IceCream's source, a little more hackery is required to get things working smoothly in Python. =]

Why do I feel like this is totally not necessary? If I am doing print() debugging, it is because I am lazy. If I want real debugging, there are better tools.

Also, print() works just fine.

very related blog post: f-string debugging in Python 3.8 [0]

which says that Python 3.8 will allow this kind of output:

    >> print(f"{name = }")
    name = 'karthikeyan'
    >>> print(f"{name.upper() = }")
    name.upper() = 'KARTHIKEYAN'

0: https://tirkarthi.github.io/programming/2019/05/08/f-string-...

Two recent discussions about related-though-not-identical Python debugging tools:

https://news.ycombinator.com/item?id=19717786

https://news.ycombinator.com/item?id=19772902

It makes sense. Debugging is often a rocky road and you have to be superman sometimes.

Agreed. Print statements are too vanilla; you need to lay down some moose tracks so you can retrace your steps once in a blue moon

I was just thinking about how i wished something like this existed. The only problem is that I always using icecream as a throw away variable name :-)

I think it's a play on "I scream", something a lot of us can associate with debugging.

Ah, thanks for pointing that out!

In addition, in the README they reference it like "ic(x)", which sounds like "I see x", and goes very well with the output that sounds like "I see x equals 5"

Bingo. This was the original intention.

"I see [X].", et cetera.

There are links to repos where this is implemented in other languages near the end of the Readme file though.

Ah, fair enough. Too late to delete/edit, sadly.