[Python-Dev] GeneratorExit inheriting from Exception

[Brett Cannon]

On 3/18/06, Barry Warsaw <barry at python.org> 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.

-Brett