Hacker News Reader

Comment by kissgyorgy | Hacker News Reader

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'

View on HN

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.

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.

You can also use the breakpoint() introduced in py3.7 via PEP533

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

Bump. This is the most correct way to debug python programs VS using print statement.

Debugging virtually anything real-time that interacts with other systems will require some kind of logging (of which printf() is the trivial case). Step-through debugging is great but far from universally applicable.

Setting a breakpoint that prints and continues is appropriate if performance doesn’t matter. It gets trickier if it does. In those cases RR seems like the best idea rather than prints. At least that’s the theory.

In my experience the conditions on the ground are different though. Tooling availability is inconsistent, which is why such approaches don’t always work. Reverse debugging isn’t available on all platforms/languages. Debuggers (or at least the C/C++ ones) are slow in how they inject instrumentation code to evaluate - rather than compiling expressions into native codes to conditionally trap, they seem to trap unconditionally and evaluate the conditional using their introspection language (there are valid reasons why it’s done this way but it has serious performance impacts). In compiled languages, the evaluation of the expression can be difficult/impossible to write because of this (not enough type information available, validation is late binding meaning mistakes are extra expensive, etc.

At the end of the day, when your tools fail you, print debugging is easier to use to accomplish the task rather. Getting tooling to work effectively is more time consuming and frequently not possible.

Correct in what way? I can think of many real time systems that cannot be debugged with a pdb breakpoint.

It's a way, it's hardly "the most correct way". Jeesh sometimes hackernews people. There are all kinds of ways to debug, and sometimes code has to run in different version of python. I find logging with various levels of "debug info" is best for me, but I hardly think that is "the most correct way"

Most correct you say? Based on what? Mind you we're talking about code that will never even ship in the vast majority of cases. Ergo, do whatever works best for you.

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

I like to use PDB++ which is a drop in replacement for PDB

https://github.com/pdbpp/pdbpp

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

> 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'

I believe the walrus operator `:=` was introduced in Python 3.8. So keep that it in mind.

As was this feature.

Indeed but the operator is useful beyond fprint

Not sure if I would consider that an improvement.

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://doc.rust-lang.org/std/macro.dbg.html

[1] https://docs.python.org/3/library/functions.html#breakpoint it's not groundsbreaking on its own but the ability to very easily hook into it and replace the breakpoint hook by an arbitrary callable? Super useful.

Do you have any concrete usage examples of that? I’ve only used breakpoint() to stop execution while debugging.

In the docs you can look up breakpoint, it has a lot of features amongst other things you can register a custom handler. I use it in selenium tests so I can either debug on error or just print the error message and continue

Could you provide a concrete example? It's still unclear to me why one wants a custom breakpoint() handler.

You can run Python with

    PYTHONBREAKPOINT=print python

and all your breakpoint() calls will be prints.

Which is not super useful, however you can use

    PYTHONBREAKPOINT=icecream.ic

and now you get the advantages of TFA without having to import anything anywhere.

The only annoyance is that the default hook takes no arguments, so you can't trivially switch between the default and custom implementations, you may need to modify the source depending on the breakpoint hook you're using.

This is how we use it in my testing repo:

__init__.py

    os.environ.setdefault('PYTHONBREAKPOINT', 'tests.utils.raise_or_debug')

tests.utils.raise_or_debug

    def raise_or_debug(msg=''):
        if settings.BREAKPOINT_ON_ERROR:
            extype, value, tb = sys.exc_info()
            if getattr(sys, 'last_traceback', None):
                pdb.pm()
            elif tb:
                pdb.post_mortem(tb)
            else:
                pdb.set_trace()
        elif msg:
            raise AssertionError(msg)
        else:
            pdb.set_trace()

The reason is so we can leave breakpoints in the tests, and then depending on context run the tests in a context where debug is possible, or simply raise the failure again.

Selenium can be very flaky, so this has really sped up iteration and improvements. Standard functions with retries, and smart assertions and timeouts can then be fixed and resumed in dev - and give a good message on fail (for example headless chrome runner on CI).

And from our own docs:

    We have manually overwritten the breakpoint handler to a custom handler that in default mode does this:
    
      - `breakpoint()` calls trigger `pdb.set_trace()` as per usual
      - `breakpoint(<str>)` calls trigger AssertionError to fail tests
    
    When `BREAKPOINT_ON_ERROR=TRUE` is turned on:
    
      - `breakpoint()` calls trigger `pdb.set_trace()` as per usual
      - `breakpoint(<str>)` call `pdb.set_trace()` so you can try to manually work out how the code is functioning
      - if you call `breakpoint(<str>)` from an `except` block it will open the debugger at the position of the exception

Usage example:

        try:
            WebDriverWait(self.driver, 10).until(
                EC.element_to_be_clickable((By.ID, 'desktop-apply')))
        except TimeoutException:
            breakpoint('Was not able to click apply button.')

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.

WHAT... Why ain't anybody talking about this? Brilliant!

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.

It was “recently” introduced in Python 3.8. See sibling for link to issue tracker

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?

No. You should use logging syntax[0] instead.

[0]: https://docs.python.org/3/library/logging.html

Wait. How does this work?

https://bugs.python.org/issue36817

Neat. Thanks. I rarely read these lists, but am fond of how friendly this proposal was!

Thank you for posting this. I will certainly use this gem extensively.

Thank you for sharing this.

Yes. Please use more of the builtins instead of adding more libraries

Reply on news.ycombinator.com