On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 3/12/07, Greg Ewing <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
