Live data from Hacker News

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

github.com

131–140 of 271 posts

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

#131

If you like this, you might also like my small debugging utility, a better_exchook replacement: https://github.com/albertz/py_better_exchook Simple example: assert x == 4 When this fails, it will print the value of `x`.

Just a point of curiosity about reassigning `sys.excepthook`. Is there a reason you simply reassign it and lose information about the old excepthook:

    sys.excepthook = better_exchook
instead of something like:

    def generate_better_exchook(..., current_excepthook=None):
        previous_excepthook = current_excepthook
        def better_exchook(exception_type, exception_instance, exception_traceback):
            ...
            if previous_excepthook is not None:
                previous_excepthook(exception_type, exception_instance, exception_traceback)
        return better_exchook
and then

    sys.excepthook = generate_better_excepthook(..., sys.excepthook)
Do you prefer not to do this because it would keep this closure around in memory until the Python process exits?

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

#132

wait isnt that just enforcing bad practice? doesnt python have proper debuggers with breakpoints ect? why in hell should i use a lib to print stuff just for debugging? i mean why not having a proper logging lib and pipe some statements to [debug] or whatever i dont get it.

Requirements for logging and debugging are quite different. For logging I probably don't want to print the source expression, I probably want to include a semantic description. For logging it is also intended to live in the code for longer, so I probably want something a touch more readable.

The debugging and logging spaces overlap but there are definitely differences if you really start optimizing for debugging experience. I don't think encouraging bad practices is a problem if the code will be deleted before being submitted.

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

#133

Earlier quoted context omitted.

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

You said "click", I need to leave my keyboard. Generally when I am coding I auto-run the tests on save. This means that to printf-debug I just add a message or two (and if I am coding I might already have a couple of useful ones lying around) and save. Then in less than a second I have a trace trough my program in the terminal. If I want to inspect a different variable I just add another print and run again. With a d…

So basically tracepoints, without touching the program code.

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

#134

Earlier quoted context omitted.

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

Depending on how complex your debugger is, it allows you to output values that might not be inspectable through the debugger. Especially computed values. Debug printing also allows you to debug programs running in environments where you can't attach a debugger. For example, maybe halting the program causes the bug not to trigger. Or it's a remote system where you cannot attach a debugger for various reasons. Or the b…

Most OS offer that with process tracing like ETW and DTrace.

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

#135

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'

Nice feature. Is there a way to globally enable/disable it? E.g., python3 myscript.py --enableFstringDebugging=true So that I could get rid of lots of conditional statements, e.g.: if debug: print (f"some useful debugging info")

Use a logger, not print, and set log level?

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

#136
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

Why would the amount of characters possibly matter?

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

#137
post #106

Earlier quoted context omitted.

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

>>> print(f"{(yes:='yes')=}") (yes:='yes')='yes'

Yep.

  >>> print(f"{(yes:='yes') = } and now {yes = }")
  (yes:='yes') = 'yes' and now yes = 'yes'

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

#138
post #88

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'

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

Not sure if I would consider that an improvement.

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

#140
post #83

Earlier quoted context omitted.

> It's quick way to narrow down the "area of search" before bringing in the big guns. What are the big guns? with a debugger, I can stick a breakpoint and look at the entire state of everything. Given we're talking about Python, in pycharm [0] you can even execute your print statements in the debugger if you so wish. If you get the location wrong, or want to see what's going on elsewhere you can just continue executi…

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?

Post reply on HN