[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