Exceptions are represented in the interpreter as (type, val, tb) triplets which most of the time contain redundant information (the type is the type of val and the tb is also on the exception). This complicates the code and is inefficient as opcodes that manage exceptions push and pop 3 items for each exception. 

We will change the internal representation to be (1) just the exception value if it is normalised and (2) a tuple of the 3 values for the uncommon case where they are all needed.

See also https://github.com/faster-cpython/ideas/issues/106.

Would there be any change at the Python level?

Initially not, neither in python nor in the c api.

It would be nice to replace PyErr_Fetch/Restore by a version that takes just an exception but that’s a long deprecation.

New changeset 05fbd60147456d77a7aecf29dddd86c5bde5872f by Irit Katriel in branch 'main':
bpo-45711: Use _PyErr_ClearExcState instead of setting only exc_value to NULL (GH-29404)
https://github.com/python/cpython/commit/05fbd60147456d77a7aecf29dddd86c5bde5872f

New changeset 4cdeee5978ee3f8ea7fe95172ae04d866cd88177 by Irit Katriel in branch 'main':
bpo-45711: remove unnecessary DUP_TOP and POP in exception handling (GH-29495)
https://github.com/python/cpython/commit/4cdeee5978ee3f8ea7fe95172ae04d866cd88177

New changeset 8f1b71de731dda668aede7c9b34d0ad7afb8f6a8 by Brandt Bucher in branch 'main':
bpo-45711: Re-bump the magic number and update doc (GH-29528)
https://github.com/python/cpython/commit/8f1b71de731dda668aede7c9b34d0ad7afb8f6a8

New changeset de3db1448b1b983eeb9f4498d07e3d2f1fb6d29d by Irit Katriel in branch 'main':
bpo-45711: assert that the type of exc_info is redundant (GH-29518)
https://github.com/python/cpython/commit/de3db1448b1b983eeb9f4498d07e3d2f1fb6d29d

New changeset c456dfafe9f9f6614fbcf2213a93707f0e101f4e by Irit Katriel in branch 'main':
bpo-45711: use exc_value instead of exc_type to determine if exc_info is valid. Add more assertions. (GH-29627)
https://github.com/python/cpython/commit/c456dfafe9f9f6614fbcf2213a93707f0e101f4e

Following the analysis/discussion on https://github.com/faster-cpython/ideas/issues/106:

* exc_info is always normalized, so we actually will never need to create a tuple of these three values (exc_curinfo, the exception raised but not yet caught can be unnormalized, but it is not pushed/popped on the stack). 

* We will reduce the interpreter's exc_info representation to just the exception instance.

* There are two APIs that are impacted, both in non-documented edge cases:

1. sys.exc_info()[2] can currently be different from sys.exc_info()[1].__traceback__ because changes to the latter (while an except clause is executing) don't show up in the former. This is arguably a bug, we will change it so that the type and traceback are always consistent with the exception.

2. PyErr_SetExcInfo does no arg checking, and will set exc_info to an inconsistent triplet if you ask it to. However, the exc_value arg must be an exception instance so the only thing you can do is pass in nonsensical args where the type/traceback do not match the exception. This function's purpose is to save/restore exc_info. We will make it ignore the type and traceback and document that change.

New changeset 8a45ca542a65ea27e7acaa44a4c833a27830e796 by Irit Katriel in branch 'main':
bpo-45711: Change exc_info related APIs to derive type and traceback from the exception instance (GH-29780)
https://github.com/python/cpython/commit/8a45ca542a65ea27e7acaa44a4c833a27830e796

New changeset 2ff758bd1a144ee712e96ae1db91f476c3b252bb by Irit Katriel in branch 'main':
bpo-45711: [asyncio] Normalize exceptions immediately after Fetch, before they are stored as StackItem, which should be normalized (GH-29890)
https://github.com/python/cpython/commit/2ff758bd1a144ee712e96ae1db91f476c3b252bb