[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0 (original) (raw)

Brett Cannon bcannon at gmail.com
Sun Jul 31 04:23:39 CEST 2005

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:

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.

I can live with this, but that will require Guido's stamp of approval.

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

I don't know if I like this change in inheritance. While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred?

I prefer the latter explanation.

-Brett

More information about the Python-Dev mailing list