[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[M.-A. Lemburg]

Brett Cannon wrote:
> Well, it has been discussed at multiple times in the past and I have
> promised to write this PEP several times, so I finally found enough
> time to write a PEP on reorganizing exceptions for Python 3.0 .
> 
> Key points in this PEP is the reworking the hierarchy, requiring
> anything raised to inherit from a certain superclass, and to change
> bare 'except' clauses to catch a specific superclass.  The first and
> last points I expect some contention, but the middle point I expect
> people are okay with (Guido liked the idea when Paul Prescod brought
> it up and the only person who didn't like it, Holger, ended up being
> okay with it when the superclass had a reasonable name).

I'm not sure what you meant with "the middle", but if this
refers to the renaming and reordering of the exception
inheritance tree, you can have my -1 on this.

I don't have any problem with making all exception inherit
from Exception and disallowing bare except clauses.

So that's a bit inverse of what you've obviously expected :-)

The reason for my -1 on the renaming and reordering is
that it would completely break compatibility of Python 2.x
applications with Python 3. Furthermore, there would be next to
no chance of writing new applications that run in Python 3
and 2, so you have breakage in both directions.

Whether this is desired or not is a different discussion,
I just want to point out some important things to consider:

When moving from Python 2.x to 3.0, renaming could be solved
with the help of some scripts, grep et al. However, there
would have to be a good reason for each of these renamings,
otherwise this only introduces additional porting overhead.
Aliases might be a way to provide soft introduction.

Something that scripts will not be able to help with are
changes in the inheritance tree, e.g. if an application
catches a ValueError, the programmer might also expect
UnicodeErrors to get caught, if the application catches
a TypeError, this may not be aware that the TypeError could
actually be an AttributeError.

Many applications define their own exception classes
which then normally inherit from StandardError. In the
application itself, you'd then usually use StandardError
for the generic "catch-all except SystemExit" try-excepts.
With the new hierarchy, catching Exception (renamed from
StandardError) would let e.g. AssertionErrors, SyntaxErrors,
etc. that may well have been produced by debugging code
or calls to compile() pass through.

Since exceptions are also used in the interpreter itself
for masking certain situations and, of course, in the
gazillion 3rd party extensions out there, your proposed
change would also have to be applied to C code - where
finding such subtleties is even harder than in plain
Python.

This is all fine, if we really intend to go for complete
breakage and basically require that Python 3 applications
need to be written from scratch.

I, for one, don't find the existing exception structure
all too bad. It has worked for me for many many years
without ever having a true need to work around some
quirks in the hierarchy. I've had these issues with some
3rd party extensions using the existing Exception class
as base-class for their own error classes in cases where
a StandardError inheritance would have been much more
appropriate, but even there, listing the exceptions
in a tuple has so far always helped.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 30 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::