On 7/30/05, M.-A. Lemburg email@example.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.