Message406984
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. |
|
Date |
User |
Action |
Args |
2021-11-25 09:53:52 | iritkatriel | set | recipients:
+ iritkatriel, gvanrossum, terry.reedy, Mark.Shannon, brandtbucher |
2021-11-25 09:53:52 | iritkatriel | set | messageid: <1637834032.27.0.501934095258.issue45711@roundup.psfhosted.org> |
2021-11-25 09:53:52 | iritkatriel | link | issue45711 messages |
2021-11-25 09:53:52 | iritkatriel | create | |
|