Mailing List Archive: Python: Dev

GeneratorExit inheriting from Exception

1 2

View All

Index | Next | Previous | View Threaded

ncoghlan at iinet

Mar 18, 2006, 4:53 AM

Post #1 of 45 (2164 views)
Permalink

GeneratorExit inheriting from Exception

Should GeneratorExit inherit from Exception or BaseException?

Currently, a generator that catches Exception and continues on to yield
another value can't be closed properly (you get a runtime error pointing out
that the generator ignored GeneratorExit).

The only decent reference I could find to it in the old PEP 348/352
discussions is Guido writing [1]:

> when GeneratorExit or StopIteration
> reach the outer level of an app, it's a bug like all the others that
> bare 'except:' WANTS to catch.

(at that point in the conversation, I believe bare except was considered the
equivalent of "except Exception:")

While I agree with what Guido says about GeneratorExit being a bug if it
reaches the outer level of an app, it seems like a bit of a trap that a
correctly written generator can't write "except Exception:" without preceding
it with an "except GeneratorExit:" that reraises the exception. Isn't that
exactly the idiom we're trying to get rid of for SystemExit and KeyboardInterrupt?

Regards,
Nick.

[1] http://mail.python.org/pipermail/python-dev/2005-August/055173.html
--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Mar 18, 2006, 7:26 AM

Post #2 of 45 (2108 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

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

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.

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

-Barry

Attachments:

signature.asc (0.30 KB)

g.brandl at gmx

Mar 18, 2006, 7:31 AM

Post #3 of 45 (2123 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw 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).
>
> 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.
>
> 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.)

Cool! That's so far the clearest solution. An additional bonus is that except
statements look nicer:

except: # still catches all Exceptions, just like
except Exception:

except Error: # is what you normally should do

Cheers,
Georg

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mattjfleming at googlemail

Mar 18, 2006, 7:39 AM

Post #4 of 45 (2111 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

>
> except Error: # is what you normally should do

+1

This definatley makes more sense and is easier to understand just from
glancing at it.

Thanks,
Matt

pedronis at strakt

Mar 18, 2006, 7:50 AM

Post #5 of 45 (2124 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw 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).
>
> 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.
>
> 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 don't know whether this is possible for Python 2.5,

well, one thing to consider is all the

class MyException(Exception):

in current code.

> but I think it
> should be what we strive for for Py3K, and I do not think BaseException
> is at all necessary.
>
> -Barry
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Mar 18, 2006, 7:51 AM

Post #6 of 45 (2114 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

On Sat, 2006-03-18 at 16:50 +0100, Samuele Pedroni wrote:

> > I don't know whether this is possible for Python 2.5,
>
> well, one thing to consider is all the
>
> class MyException(Exception):
>
> in current code.

Yep, which is why I'm not sure we can do this for Py2.5. However as PEP
352 talks about a transition plan for Py3k, I think we should document
the ultimate desired hierarchy (and maybe implement that in the p3yk
branch ;), and then think about how to transition to it in Py2.5.

One possible approach is to revert BaseException out of Py2.5,
re-position KeyboardInterrupt, and add Error as an alias for
StandardError. Then we can encourage people to start using Error as the
base classes for their own errors.

-Barry

Attachments:

signature.asc (0.30 KB)

rasky at develer

Mar 18, 2006, 10:32 AM

Post #7 of 45 (2108 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Georg Brandl <g.brandl [at] gmx> wrote:

>> Exception
>> +- KeyboardInterrupt
>> +- GeneratorExit
>> +- SystemExit
>> +- StopIteration
>> +- Error
>>> +- ImportError
>>> +- (etc.)
>>>
>> +- Warning
>> +- UserWarning
>> +- (etc.)
>
> Cool! That's so far the clearest solution. An additional bonus is that
> except
> statements look nicer:
>
> except: # still catches all Exceptions, just like
> except Exception:
>
> except Error: # is what you normally should do

+1 on the general idea, I just don't specifically like that "except:" is the
"wrong" thing to do: part of the PEP352 idea was that people writing
"except:" out of ignorance would still not cause their program to intercept
KeyboardInterrupt, or StopIteration.

Unless this new proposal also includes changing the meaning of "except:" to
"except Error". Also, under this new proposal, we could even remove
Exception from the builtins namespace in Py3k. It's almost always wrong to
use it, and if you really really need it, it's spelled exceptions.Exception.
--
Giovanni Bajo

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Mar 18, 2006, 10:50 AM

Post #8 of 45 (2109 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:

> +1 on the general idea, I just don't specifically like that "except:" is the
> "wrong" thing to do: part of the PEP352 idea was that people writing
> "except:" out of ignorance would still not cause their program to intercept
> KeyboardInterrupt, or StopIteration.
>
> Unless this new proposal also includes changing the meaning of "except:" to
> "except Error".

It's worth debating. OT1H, it's a semantic different for Python 2.x
(although +1 on the idea for Py3K). OTOH, I think people generally want
to just catch errors and not all exceptions. Going along with that,
maybe the interpreter should do something different when an Exception
that's not an Error reaches the top (e.g. not print a traceback if
KeyboardInterrupt is seen -- we usually just catch that, print
"Interrupted" and exit).

> Also, under this new proposal, we could even remove
> Exception from the builtins namespace in Py3k. It's almost always wrong to
> use it, and if you really really need it, it's spelled exceptions.Exception.

I'm not sure I'd go as far as hiding Exception, since I don't think the
penalty is that great and it makes it easier to document.

-Barry

Attachments:

signature.asc (0.30 KB)

rasky at develer

Mar 18, 2006, 11:13 AM

Post #9 of 45 (2128 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw wrote:

> >Unless this new proposal also includes changing the meaning of
>> "except:" to "except Error".

> It's worth debating. OT1H, it's a semantic different for Python 2.x
> (although +1 on the idea for Py3K).

I was speaking of Py3K here, yes.

> Going along with that, maybe the interpreter should do something
> different when an Exception that's not an Error reaches the top
> (e.g. not print a traceback if KeyboardInterrupt is seen --
> we usually just catch that, print "Interrupted" and exit).

SystemExit is already special-cased, as far as I can tell. KeyboardInterrupt
could be in fact be special cased as well (I saw many Python newbies -- but
otherwise experienced -- being disgusted at first when they interrupt their
code with CTRL+C: they expect the program to exit "almost silently").

>> Also, under this new proposal, we could even remove
>> Exception from the builtins namespace in Py3k. It's almost
>> always wrong to use it, and if you really really need it, it's
>> spelled exceptions.Exception.

> I'm not sure I'd go as far as hiding Exception, since I don't think the
> penalty is that great and it makes it easier to document.

The situation (in Py3k) I was thinking is when people see this code:

except:
# something

and want to change it so to get a name to the exception object. I *think* many
could get confused and write:

except Exception, e:
# something

which changes the meaning. It "sounds" correct, but it's wrong. Of course, it's
easy to argue that "Exception" is just that, and people actually meant "Error".
In a way, the current PEP352 is superior here because it makes harder to do the
"bad" thing by giving it a complex name (BaseException).

Giovanni Bajo

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

brett at python

Mar 18, 2006, 3:37 PM

Post #10 of 45 (2109 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

On 3/18/06, Barry Warsaw <barry [at] python> 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
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Mar 18, 2006, 5:48 PM

Post #11 of 45 (2112 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw wrote:
> On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:

>>Unless this new proposal also includes changing the meaning of "except:" to
>>"except Error".

Then maybe it should be called "error:" rather
than "except:". :-)

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Mar 18, 2006, 5:49 PM

Post #12 of 45 (2111 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw wrote:

> One possible approach is to revert BaseException out of Py2.5,
> re-position KeyboardInterrupt, and add Error as an alias for
> StandardError. Then we can encourage people to start using Error as the
> base classes for their own errors.

Also maybe start issuing warnings whenever you inherit
directly from Exception.

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Mar 18, 2006, 5:49 PM

Post #13 of 45 (2110 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw wrote:

> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> | +- ImportError
> | +- (etc.)
> |
> +- Warning
> +- UserWarning
> +- (etc.)

+42! This is beautifully clear and simple, especially
compared to some of the other exception hierarchy
reorganisations that have been proposed.

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Mar 18, 2006, 5:50 PM

Post #14 of 45 (2110 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Giovanni Bajo wrote:

> The situation (in Py3k) I was thinking is when people see this code:
>
> except:
> # something
>
> and want to change it so to get a name to the exception object. I *think* many
> could get confused and write:
>
> except Exception, e:
> # something

If except clauses are changed to use "as", then
as long as we're still allowing bare excepts, that
could become

except as e:
...

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

tjreedy at udel

Mar 18, 2006, 6:33 PM

Post #15 of 45 (2111 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Exception
+- KeyboardInterrupt
+- GeneratorExit
+- SystemExit
+- StopIteration

This would look even better to me and be easier to learn and remember if
the above specifics were gathered under one general category parallel to
Error and Warning. Not sure what. Not NonErrorNonWarning though.
SystemException is too long and too specific. Maybe Control?

No, I don't have a specific use other than didactic, but that is worth
something, and I can imagine that someone else might.

+- Error
| +- ImportError
| +- (etc.)
|
+- Warning
+- UserWarning
+- (etc.)

Otherwise, looks good to me.

Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Mar 18, 2006, 6:35 PM

Post #16 of 45 (2130 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Barry Warsaw wrote:
> 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 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.

The main problems I have with the idea are the fact that a large fraction of
the user-defined exceptions out there already inherit from Exception (and this
has been pushed for a long time as the right thing to do) and the fact that
"except Exception:" has also been pushed for years as the preferred
alternative to a bare "except:".

Rather than trying to change course midstream, I *like* the fact that the PEP
352 hierarchy introduces BaseException to bring the language itself into line
with what people have already been taught. Breaking things in Py3k is all well
and good, but breaking them gratuitously is something else entirely :)

I also agree with the point made during the PEP 348/352 discussions that
StopIteration reaching any except clause that isn't specifically expecting it
*is* an error. Direct calls to an iterator's next method need to expect the
StopIteration and decide how to handle it - not handling it is a bug.

For KeyboardInterrupt/SystemExit/GeneratorExit, it is clear that the standard
behaviour should be to reraise them - the entire point of those exceptions is
to shut down an entire call stack. StopIteration, on the other hand, merely
indicates that a particular iterator has completed, not that the entire stack
of iterators should be shut down.

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Mar 18, 2006, 6:58 PM

Post #17 of 45 (2131 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Terry Reedy wrote:
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
>
> This would look even better to me and be easier to learn and remember if
> the above specifics were gathered under one general category parallel to
> Error and Warning. Not sure what. Not NonErrorNonWarning though.
> SystemException is too long and too specific. Maybe Control?
>
> No, I don't have a specific use other than didactic, but that is worth
> something, and I can imagine that someone else might.

I'd vote for ControlFlowException if StopIteration is included in the
category, and TerminatingException if it isn't.

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

just at letterror

Mar 18, 2006, 11:05 PM

Post #18 of 45 (2110 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Greg Ewing wrote:

> Barry Warsaw wrote:
>
> > One possible approach is to revert BaseException out of Py2.5,
> > re-position KeyboardInterrupt, and add Error as an alias for
> > StandardError. Then we can encourage people to start using Error
> > as the base classes for their own errors.
>
> Also maybe start issuing warnings whenever you inherit
> directly from Exception.

Ugh. I hate it when it's made (virtually) impossible to write code that
runs warnings-free on both Python X.Y and X.(Y+1).

Just
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Mar 18, 2006, 11:31 PM

Post #19 of 45 (2131 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Just van Rossum wrote:
> Greg Ewing wrote:
>
>> Barry Warsaw wrote:
>>
>>> One possible approach is to revert BaseException out of Py2.5,
>>> re-position KeyboardInterrupt, and add Error as an alias for
>>> StandardError. Then we can encourage people to start using Error
>>> as the base classes for their own errors.
>> Also maybe start issuing warnings whenever you inherit
>> directly from Exception.
>
> Ugh. I hate it when it's made (virtually) impossible to write code that
> runs warnings-free on both Python X.Y and X.(Y+1).

This was one of the key things that led to the approach in PEP 352. Barry's
hierarchy is very similar to some of the suggestions made during the PEP 348
discussion, and they were rejected because they made the transition a hell of
a lot harder without any concomitant benefit. I know this because I was one of
the people making those suggestions.

With PEP 352 (tweaked to move GeneratorExit out from under Exception):
- "except:" continues to mean catch everything
- "except Exception:" now does the right thing
- inheriting from Exception continues to be correct for user exceptions
- errors may choose to inherit from one of the existing Errors instead

With Barry's proposed hierarchy:
- "except:" continues to mean catch everything
- "except Exception:" continues to do the wrong thing
- all code has to change to do "except Error:" instead
- inheriting from Exception becomes incorrect for user exceptions
- all code has to change to inherit from Error instead
- non-error user exceptions (such as completion of a search using nested
loops) have no clear parent to inherit from (both Error and Exception
are wrong, albeit for different reasons.

The additional pain required in order to have 'Exception' at the root of the
hierarchy just isn't worth it.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

rasky at develer

Mar 19, 2006, 3:43 AM

Post #20 of 45 (2111 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Nick Coghlan <ncoghlan [at] gmail> wrote:

> Rather than trying to change course midstream, I *like* the fact that
> the PEP 352 hierarchy introduces BaseException to bring the language
> itself into line with what people have already been taught. Breaking
> things in Py3k is all well and good, but breaking them gratuitously
> is something else entirely :)

I really like this too, but Barry's proposal doesn't really *break* anything.
Existing Python code that creates a FooBar(Exception) and then catches it with
either "except FooBar:" or "except Exception, e:" + check for FooBar, will
still work as expected. At *worse*, it would be catching too much, like
SystemExit or GeneratorExit, which are still pretty uncommon exception.

OTOH, I also understand that people have been told that deriving from Exception
is the right thing to do forever now.

Giovanni Bajo

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Mar 19, 2006, 6:16 PM

Post #21 of 45 (2106 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Just van Rossum wrote:
> Greg Ewing wrote:
>
> > Also maybe start issuing warnings whenever you inherit
> > directly from Exception.
>
> Ugh. I hate it when it's made (virtually) impossible to write code that
> runs warnings-free on both Python X.Y and X.(Y+1).

Yes, that could be a problem. Maybe there could be a
__future__ import which says "I know about the new
exception scheme, trust me when I inherit from
Exception."

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Mar 19, 2006, 6:40 PM

Post #22 of 45 (2111 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Sigh. Enough already. PEP 352 was chosen to minimize incompatibilities
and maximize gain with minimal changes in the tree. Also note that
Warnings can sometimes be raised and should then treated as errors, so
Warning would have to inherit from Error.

I vote for the status quo in HEAD, except I've got to think more about
the pros and cons of making GeneratorExit as special as
KeyboardInterrupt.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Mar 19, 2006, 6:45 PM

Post #23 of 45 (2115 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

Giovanni Bajo wrote:

> OTOH, I also understand that people have been told that deriving from Exception
> is the right thing to do forever now.

Have we really being telling them to derive *directly*
from Exception, or just that deriving somehow from
Exception will become mandatory?

For the purpose of minimising bare-except problems,
recommending direct derivation from Exception seems
like a particularly bad idea, whether the exception
hierarchy is changed or not.

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Mar 19, 2006, 7:18 PM

Post #24 of 45 (2115 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

On 3/19/06, Greg Ewing <greg.ewing [at] canterbury> wrote:
> Have we really being telling them to derive *directly*
> from Exception, or just that deriving somehow from
> Exception will become mandatory?

It doesn't matter. Most code that tries to be a good citizen today
derives its exceptions from Exception.

> For the purpose of minimising bare-except problems,
> recommending direct derivation from Exception seems
> like a particularly bad idea, whether the exception
> hierarchy is changed or not.

Why? With PEP 352 (== HEAD status quo) this works just fine.

I have a problem with using Error as the focal point since so many
exceptions (user-defined or otherwise) aren't errors. Not to mention
the Warnings which sometimes can be raised as Errors (but without
changing their type).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

raymond.hettinger at verizon

Mar 20, 2006, 12:49 AM

Post #25 of 45 (2106 views)
Permalink

Re: GeneratorExit inheriting from Exception [In reply to]

[Guido]
> Sigh. Enough already. PEP 352 was chosen to minimize incompatibilities
> and maximize gain with minimal changes in the tree. Also note that
> Warnings can sometimes be raised and should then treated as errors, so
> Warning would have to inherit from Error.
>
> I vote for the status quo in HEAD, except I've got to think more about
> the pros and cons of making GeneratorExit as special as
> KeyboardInterrupt.

While Guido is thinking, could one of the proponents please enumerate the
reasons for treating GeneratorExit like KeyboardInterrupt and SystemExit.

To me, they obviously should be under Exception, and not treated like
KeyboardInterrupt or SystemExit, so that probably means that I'm missing
something about GeneratorExit.

Raymond

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads