[Python-3000] exception info [was: Discussions with no PEPs]

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 get_tb(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 'yes_I_know_I_need_to_clear_the_traceback' 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
> get_tb() 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.


 - Josiah

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