Author iritkatriel
Recipients Mark.Shannon, brandtbucher, gvanrossum, iritkatriel, terry.reedy
Date 2021-11-25.09:53:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1637834032.27.0.501934095258.issue45711@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2021-11-25 09:53:52iritkatrielsetrecipients: + iritkatriel, gvanrossum, terry.reedy, Mark.Shannon, brandtbucher
2021-11-25 09:53:52iritkatrielsetmessageid: <1637834032.27.0.501934095258.issue45711@roundup.psfhosted.org>
2021-11-25 09:53:52iritkatriellinkissue45711 messages
2021-11-25 09:53:52iritkatrielcreate