[Python-Dev] Exception and new-style classes

Phillip J. Eby pje at telecommunity.com
Wed Aug 4 18:22:51 CEST 2004

At 07:34 AM 8/4/04 -0700, Guido van Rossum wrote:
> > > Probably not, but making Exception a new-style class won't be easy.
> >
> > What makes you say that?  I've just been remarking on
> > comp.lang.python how having Exception be new-style in PyPy --
> > indeed, not having old-style classes and all -- has caused
> > essentially no problems at all.
>I believe that -- it's more that the existing infrastructure that
>creates the standard exception hierarchy isn't easily adapted.
>I also believe there's a conceptual problem with defining when
>something is an acceptable argument to 'raise' -- unless we insist
>that exceptions inherit from a designated base class, *every* object
>is acceptable, because if it isn't a class, it's an instance of a
>class, and raise allows either.  I don't really think that "raise 42"
>ought to be acceptable, but I don't know how to prevent it without
>requiring a specific base class (excluding a whole slew of specific
>base classes seems wrong).
>Maybe we can accept old-style classes and instances, strings, and
>instances of Exception and its subclasses.  But then we better be sure
>that we really want to insist on subclassing from Exception, because
>that's rather unpythonic.

I thought that was already the plan; I seem to recall dire warnings that it 
was going to be required someday.

In any case, I had my eye on "fixing" this for next bug day (there's a SF 
bug # for it, that I don't recall at the moment).

My plan was to allow any object that was an instance of Exception, even if 
it was new-style.  In other words, new-style exceptions would have to 
include Exception in their base classes.  Old-style exceptions wouldn't 
have to meet that requirement, for backward compatibility purposes.

I assumed that the old-style (and string) compatibility would need to 
remain until 3.0.

More information about the Python-Dev mailing list