On 26 March 2015 at 22:30, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
Here is the first draft of my PEP to chain automatically exceptions at C level in Python 3.5. Plain text version of the PEP below. HTML version of the PEP:
https://www.python.org/dev/peps/pep-0490/
It has already an implementation, the pyerr_chain.patch file attached to http://bugs.python.org/issue23763
The patch is very short.
I like the idea, but I think it would raise the priority of the proposed change to the display of chained exceptions in http://bugs.python.org/issue12535 That proposal suggests adding the line "<truncated: another exception occurred>" to the start of earlier tracebacks in the chain so you get an up front hint that a chained exception will be shown after the initial traceback.
Backward compatibility ======================
A side effect of chaining exceptions is that exceptions store traceback objects which store frame objects which store local variables. Local variables are kept alive by exceptions. A common issue is a reference cycle between local variables and exceptions: an exception is stored in a local variable and the frame indirectly stored in the exception. The cycle only impacts applications storing exceptions.
The reference cycle can now be fixed with the new ``traceback.TracebackException`` object introduced in Python 3.5. It stores informations required to format a full textual traceback without storing local variables.
Also potentially worth noting here is "traceback.clear_frames()", introduced in 3.4 to explicitly clear local variables from a traceback: https://docs.python.org/3/library/traceback.html#traceback.clear_frames PEP 442 also makes it more likely that cycles will be cleared properly, even if some of the objects involved have __del__ methods: https://www.python.org/dev/peps/pep-0442/ However, I'll grant that neither of those can be backported the way that traceback.TracebackException can be. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia