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 ! :::: _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
