mcherm at mcherm.com
Tue Jun 10 16:30:02 CEST 2003
> 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
> raise Class, arguments
> in favor of
> raise Class()
> 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
raise MyError, raised
except MyError, caught:
Looks like "raised" is the same object as "caught". But it's
(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