PEP 678: Enriching Exceptions with Notes

[iritkatriel]

Thank you to the SC and to everyone who participated in the discussion. The final PEP is definitely better than what we started with!

[Conchylicultor (Etienne Pot)]

@Zac-HD

I think Irit is talking about using the stdlib traceback module to globally customize exception display.

As explained above, I don’t think this is a realistic option as:

• It would conflict with pytest, ipython,… (which already customize the traceback)
• It would conflict with user own traceback customization
• If all libraries were doing this, libraries would conflict with each other
• Having a library which has global side-effects would be confusing/unexpected for users

@iritkatriel

We are not suggesting to mutate the traceback , but to use the building blocks in traceback to control how an exception is rendered (at the time of rendering, not at library import time)

Looking at the code example from @Zac-HD, exceptiongroup is mutating the traceback module at import time.

Did I miss something ? Is there a way to locally control how an exception is rendered without global side-effect ?

@iritkatriel

str(e) is currently called at the time of the exception’s rendering.

One option would have be to have some class LazyStr(str), so that the actuall str is never computed if not accessed.

There would probably be also many other options and API to allow customizing traceback.

My feeling is that if we had done a pooling for on the Python community about which feature are more important between:

1. Supporting i18n translation
2. Flexible formating (control the position where the notes are added)

I think more users would have been interested by (2), so I’m surprised only (1) was fixed.

[gpshead (Gregory P. Smith)]

@Conchylicultor

My feeling is that if we had done a pooling for on the Python community about which feature are more important between:

1. Supporting i18n translation
2. Flexible formating (control the position where the notes are added)

I think more users would have been interested by (2), so I’m surprised only (1) was fixed.

I see this as keeping this PEP focused and relatively simple.

There is room for potential improvement in our Traceback machinery in future releases if someone wants to drive defining what they’d like to see there. (example wish: it’d be nice to be able to expose them in a structural unambiguious format for machine processing rather than the semi-arbitrary text they can be today)

If we tried to address everyone’s desires all at once when doing anything or do nothing at all, nothing would ever happen.