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

Collin Winter collinw at gmail.com
Tue Mar 13 01:58:07 CET 2007

On 3/12/07, Guido van Rossum <guido at python.org> wrote:

On 3/12/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > Guido van Rossum wrote: > > I'm still hoping we can get agreement that storing the traceback on > > the exception object is the way to go. Only a handful of modules using > > pre-baked exception objects would have to be fixed, and likely those > > were doing it out of a misunderstanding of the performance > > characteristics. > > One more thought on this -- do we still think it's a > good idea to make it possible to raise and catch an > exception in C code without instantiating anything?

I don't see it's contradictory to the proposal.

I think it should be kept. During my first pass at implementing PEPs 3110, I tried replacing all the places in C that raise non-instantiated exceptions with instantiating alternatives. It turned out to be a tedious pain in the ass. Of course, if someone else is doing the work... ; )

> If so, how does this interact with the idea of > attaching the traceback to the exception?

The internal mechanism for bubbling an exception up the stack until an except clause catches it could continue to use the (class, instance, traceback) triple, and if raise is passed a class instead of an instance, the instance would be NULL; when forced to instantiate the exception, the traceback collected up to that point is attached to it. If an instance was passed to raise, the traceback pointer in the instance is updated each time we leave a stack frame. I think this means the traceback attribute needs to correspond to a C-level slot in the BaseException instance lay-out.

This a good summary of the strategy I've taken while implementing PEP 344.

Collin Winter

More information about the Python-3000 mailing list