Irit Katriel <iritkatr...@gmail.com> added the comment:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45711> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
