j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 3/18/06, Barry Warsaw email@example.com wrote:
On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
Should GeneratorExit inherit from Exception or BaseException?
Actually, this prompts me to write about an issue I have with PEP 352. I actually don't think it's necessary (yes, I know it's already in the tree).
Much to personal pain and sprint time. Are you trying to make me shed a manly tear, Barry?!? =)
What I would much rather is is for StandardError to be renamed Error, for Exception to remain the base class of the exception hierarchy, and for KeyboardInterrupt to be moved to inherit directly from Exception. GeneratorExit, SystemExit, and StopIteration would continue to inherit from Exception.
So it isn't that PEP 352 is unnecessary since there is nothing here about deprecating string execptions and making built-in exceptions new-style. You just want to change the renaming of the exceptions.
The reasoning is this: anything that can be raised is an Exception. Not all Exceptions are Errors. Anything that signals an error condition is an Error, and anything that signals a warning condition is a Warning. Thus the basic hierarchy /ought/ to be:
Exception +- KeyboardInterrupt +- GeneratorExit +- SystemExit +- StopIteration +- Error | +- ImportError | +- (etc.) | +- Warning +- UserWarning +- (etc.)
Use defined errors should inherit from Error, not Exception. With this, "except Exception" would be a synonym for bare except, while "except Error" would be the standard idiom for letting non-error exceptions pass through.
I still like my idea of a ControlFlowException, but that died with PEP 348 (along with part of my innocence).
I don't know whether this is possible for Python 2.5, but I think it should be what we strive for for Py3K, and I do not think BaseException is at all necessary.
I view PEP 352 as the PEP that fixed an issue with overreaching 'except' clauses, officially getting us off of string exceptions, and making built-in exceptions new-style classes. I do not view it as the be-all-end-all hierarchy for Py3K.
With that said, I am not changing the PEP. Another PEP that suggests the hierarchy for Py3K can be suggested, but I am not doing it. I am totally burned out on exceptions after two PEPs on the subject matter.
Just remember that PEP 348 was meant for Py3K when we are supposed to break stuff and how much resistence I hit. Granted my changes were more radical, but even in the end, small changes were resisted heavily. In other words, make sure you have the time and energy to take this on. =)
But the above suggestions seem reasonable, especially if bare 'except' statements go away. So I am supportive of the idea.