[Python-3000] simplifying the exception mechanism

tomer filiba tomerfiliba at gmail.com
Tue Jan 23 10:42:29 CET 2007


well, if it helps improve speed, than that's fine. although
i don't see how really.

first of all, exceptions raised by python code must be
normalized as the code might need the exception object, i.e.

try:
    foo
except bar:
    ex = sys.exc_info()

so the only place it's meaningful is exceptions raised by
the core that are also caught by the core. the only place
where that happens is, afaict, in the getattr mechanism.

well, i guess it's important enough to keep that code fast.


-tomer

On 1/23/07, Brett Cannon <brett at python.org> wrote:
> On 1/22/07, Collin Winter <collinw at gmail.com> wrote:
> > On 1/22/07, tomer filiba <tomerfiliba at gmail.com> wrote:
> > > with all the talk about enhancing exceptions and removing unnecessary
> > > functions from the codebase, i think we can also drop
> > > PyErr_NormalizeException and friends.
> >
> > One argument in favor of keeping PyErr_NormalizeException() (as I've
> > learned from trying to rip it out) is the speed advantage it brings.
> > It's less expensive to sock away the exception class and arguments,
> > only instancing the exception when you really need it. This is
> > important in certain core types, where light(er)-weight exception
> > raising comes in handy.
> >
>
> I'm with Collin on this one.  The speed argument is one of the reasons
> PyErr_NormalizeException even exists.  We want exceptions in the
> simple, general case to be as fast as possible.
>
> -Brett
>


More information about the Python-3000 mailing list