On 7/30/05, Nick Coghlan
M.-A. Lemburg wrote:
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.
I think the problems with this can be minimised by avoiding making changes we don't need to. I think only a few changes are needed to get a significantly cleaner structure.
Here's a fairly minimal proposal, which is closer to the existing 2.4 structure:
Nick, are you going go start subbing in for Tim when he is busy and take my work that I spent hours on, come up with an alternative that took 10 minutes, and have everyone end up loving your newfangled idea 10x more than my original? =)
New Hierarchy =============
Raisable (formerly Exception) +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- ControlFlowException (new)
As I have said I am fine with moving ControlFlowException out to here, but it depends if others agree.
+-- GeneratorExit +-- StopIteration +-- SystemExit
Good point with SystemExit! I am definitely +1 on changing that inheritance.
+-- Exception (formerly StandardError) +-- AssertionError +-- AttributeError
I am still up for moving AttributeError, but with the amount of arguing going on between where it should go I am not going to be shocked if we go with the status quo.
+-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError) +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- EnvironmentError +-- OSError +-- WindowsError (possibly remove this from builtins)
If we are going to lack exceptions for other OSs, I say remove it. No reason Windows should get special treatment with a built-in exception.
+-- IOError +-- EOFError +-- LookupError +-- IndexError +-- KeyError +-- NameError +-- UnboundLocalError
What about UnboundGlobalError?
+-- RuntimeError
I still don't like the name.
+-- NotImplementedError
Interesting idea, but I don't view them as the same. Everyone uses RuntimeError as a Poor Man's Exception, not as an actual runtime error.
+-- SyntaxError +-- IndentationError +-- TabError +-- ValueError +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- FutureWarning +-- PendingDeprecationWarning
Don't like the idea of having DeprecationWarning inherit from PendingDeprecationWarning? -Brett