PEP-317

Michael Chermside mcherm at mcherm.com
Tue Jun 10 10:30:02 EDT 2003


Guido writes:
> There seem to be lots of different things in that PEP (I've got no
> time to read it in full).

Too bad... it's well written.

> - deprecating string exceptions: definitely
> 
> - making all exceptions derive from Exception: most probably

Not actually part of this PEP... the author is going for the
minimal PEP possible. But maybe it should be added.

> - making Exception a new-style class: eventually

Not really possible without this PEP.

Basically, the PEP is all about the migration plan, without
dealing much with the end point. It says "we all know string
exceptions should go. Let's also say that eventually we'll
use new-style classes, and maybe pack some extra functionality
into the Exception class. Let's start the deprecation and
warnings now." And it carefully considers all the kinds of code
breakage and how to handle it.

> But I'm not at all happy with the proposed deprecation of
> 
>   raise Class
> 
> and
> 
>   raise Class, arguments
> 
> in favor of
> 
>   raise Class()
> 
> and
> 
>   raise Class(arguments)
> 
> I don't see how this change is necessary in order to get any of the
> other benefits.

(1) There should be only one (preferably obvious) way to do it.
(2) If I write "raise x" is that an example of "raise Class", or
    of "raise instance"? With old-style exceptions, you have to
    examine the type of x to figure out what to do. With new-style
    exceptions, even that wouldn't do.
(3) The "raise Class" form has a spurious similarity with the
    except clause:
        try:
            raise MyError, raised
        except MyError, caught:
            pass
    Looks like "raised" is the same object as "caught". But it's
    not.
(4) There's no benefit to having two syntaxes. See (1).


> I also don't understand the commotion over deferred exception
> instantiation, since it doesn't happen except for exceptions
> raised from C code.

Ignore it... it's a red herring. The whole deferred exception thing
is just an implementation detail at the C level.

-- Michael Chermside






More information about the Python-list mailing list