Phillip J. Eby wrote:
I like this a lot, and a good bit of it could actually be done in 2.5, apart from the Exception/StandardError move, assuming also that the renamed errors were also available under their old names. We could probably go so far as to add Raisable to the hierarchy, but I don't think we could actually get quite to your proposed structure without breaking any programs. On the other hand, if we introduce CriticalException and ControlFlowException in 2.5 (inheriting from Exception), and create a new Error base for StandardError, then promote subclassing and catching it instead of Exception, then there will be less to do in 3.0. So, my thoughts for the 2.x series are:
Exception CriticalException ControlFlowException Error StandardError
If we leave Exception at the top of the hierarchy for Py3k, and use Error to replace StandardError, the hierarchy could look like this:
Exception +-- ControlFlowException (new) +-- GeneratorExit +-- KeyboardInterrupt +-- StopIteration +-- SystemExit +-- CriticalError (new) +-- MemoryError +-- SystemError +-- Error (formerly StandardError) +-- AssertionError +-- AttributeError +-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError)
I wouldn't mind using Exception/Error instead of Raisable/Exception - and it seriously reduces the pain of making this transition. Indeed, most of it becomes doable within the 2.x series - the only tricky parts are semantic changes involved with moving the KeyboardInterrupt, MemoryError and SystemError out from under StandardError, and moving EOFError under IOError.
So the question is whether or not the Raisable/Exception combination is liked enough that we want to dance through the requisite hoops to get there.
Notice that I've classified KeyboardInterrupt as user-initiated control flow and put it under ControlFlowException above. This means that everything under CriticalError and Error actually ends with the word 'Error'.