[Python-3000] exception info [was: Discussions with no PEPs] (original) (raw)

Josiah Carlson jcarlson at uci.edu
Wed Mar 14 02:56:47 CET 2007

"Guido van Rossum" <guido at python.org> wrote:

[adding back the list]

(oops)

On 3/13/07, Josiah Carlson <jcarlson at uci.edu> wrote: > What if the thing to the right of 'as' were assigned different values > depending on what it was? If it were one name, it would be the > exception (without traceback) "except ... as foo". If it was a 3-tuple > of names, it would get all three: "except ... as ecls, e, tb:". (with 2, > maybe e and tb) Anything else could raise a SyntaxError during the code > generation phase. > > In cases where we get a tb, we can clear the traceback at the end of the > except clause without needing to clear the exception, etc. Whether or > not the traceback exists as an attribute of the exception would then > become an implementation detail. For cases where we pass an exception > instance around, I would introduce a function called gettb(e) (in > either sys or traceback) that takes the exception object and returns the > traceback. Whether or not it should print a warning unless the > keyword-only argument of 'yesIknowIneedtoclearthetraceback' is > provided and is True, or if it returns a weakref, I'll leave to someone > else's discretion.

That sounds like too much complexity (both the syntax proposal and the gettb() API). With the new GC, clearing the traceback is really not all that important any more except in the vicinity of buggy code that expects that leaving a scope GC's its locals; apart from that it's more of a performance issue than anything else, so I don't see why we can't just have traceback on the exception object.

The point of get_tb() would be to help prevent people from getting at the traceback unless they really needed it. If I remember the discussion about 'x = sys.exc_info()' and/or the automatic clearing of the name in the 'except ... as name:' syntax, the reason for clearing the exception and traceback from the locals was to prevent cycle issues, etc. By requiring people to be explicit about when they wanted the traceback (rather than giving it to them all the time via e.traceback), we can prevent many of those issues. Also, with a little work, we can force users to at least acknowledge proper cleanup semantics.

I'll presume this idea is rejected, no need to reply.

In order to get maximum benefit from the 'give me the traceback', really it would take two dictionaries, one that is a mapping from exception instances to threads, and a second that is a mapping from threads to (exception instance, traceback) tuples. All current and proposed semantics are easily derived from these two structures (my reading of the sys.exc_* functions suggest that something like this already exists, though is perhaps attached to the thread, and not in a dictionary).

More information about the Python-3000 mailing list