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

[Brett Cannon]

On 7/30/05, M.-A. Lemburg <mal at egenix.com> wrote:
> 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",


Actually, it was referencing the bare 'except' clauses and changing
their semantics.

> 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.
> 

Do you mean all inherit from Exception in order for it be allowed to
be passed to 'raise'?

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

If this becomes a theme, yes.  But specifically coming from you, MAL,
no, not really.  =)

> 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.
> 

My view of Python 3.0 was that backwards-compatibility would not be a
gimme in anyway.  I personally am willing to break stuff in the name
of clarity, which is the point of this whole endeavour.  While I am
willing to back off on some the proposed changes, I do think the basic
spirit of it is correct.

> 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.
> 

Right, so the renaming is not a huge problem.

> 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.
> 

Right, but if we introduce aliases in Python 2.9 or sooner the
transition will be much easier and they will know to rename things.

And obviously warnings can be used for people to know that the
hierarchy will change.   I bet we will put in a
PendingDeprecationWarning or SemanticsWarning saying that the
inheritance will be different in Python 3.0 .

Yes, this will incur more work than had we left it alone, but the
whole point of Python 3.0 is to remove quirks.

> 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.
> 

If we fiddle with the exception code raising a Warning will not be too
bad for this.  Plus you can grep for PyExc_TypeError easily enough to
see where you are using classes that have a new inheritance tree.

> 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 expect Python 2.x code to run automatically without
some fiddling.  I think saying from scratch is a little strong.

> 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.
> 

Lot's of things "just work", but it doesn't mean they can't be improved upon.

But it looks like some of my suggestions were overreaching so they
will most likely get scaled back.  I will also add a section to the
PEP discussing how a transition from Python 2.x to Python 3.0 in this
regard can be handled.

-Brett