-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Re: the discussion in:
http://mail.python.org/pipermail/python-dev/2006-March/062823.html
Just as an FYI, the tlslite package (http://trevp.net/tlslite/) got
broken in Python 2.5 and needed the exact fix quoted in the URL above.
It was an easy fix,
Guido van Rossum wrote:
> On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> The kind of code I'm talking about would be an *existing* Python 2.4
>> generator
>> that happens to do something like:
>>
>>def gen(tasks):
>>"""yield the results of a bunch of task functions"""
>>
On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The kind of code I'm talking about would be an *existing* Python 2.4 generator
> that happens to do something like:
>
>def gen(tasks):
>"""yield the results of a bunch of task functions"""
>for task in tasks:
>try
>> I can't see all that much use for GeneratorExit in code that needs to
>> be compatible with 2.4, since the rest of the machinery that makes
>> exception handling around yield feasible doesn't exist.
>
> I agree entirely - my goal is to make sure it stays that way.
>
> The kind of code I'm talkin
Guido van Rossum wrote:
> On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> OTOH, if GeneratorExit inherits from Exception (as in current SVN), then two
>> things will be needed to make the generator work correctly:
>>
>> 1. add a preceding exception clause to fix Python 2.5 behaviour:
>>e
On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The last comment I heard from Guido on this topic was that he was still
> thinking about it.
Not exactly. I'm delegating the thinking mostly to others.
> However, I now have an additional data point - if GeneratorExit inherits
> directly from
Nick Coghlan wrote:
> 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 onl
Michael Chermside <[EMAIL PROTECTED]> wrote:
>
> Barry writes:
> > I still believe in this, and I'm thankful for the support I've seen. It
> > won't happen for Python 2.x, but I do plan on addressing this for Py3K.
>
> When you do, I'd like you to consider one change to the names. You are
> pro
Aahz wrote:
> > Also maybe start issuing warnings whenever you inherit directly from
> > Exception.
>
> -1 -- I occasionally use exceptions as a multi-loop break. That's a
> perfectly valid Python practice, those exceptions should inherit from
> Exception, and there should not be any warnings ra
Barry Warsaw wrote:
> Ideally, StandardError would be called
> Error ... Their non-error exceptions
> would be derived from Exception.
Having something called StandardError suggests that
there are "non-standard errors" around somewhere.
Are we to have Error Police going around making
sure everyo
Barry Warsaw wrote:
> One quibble. Since the term used for the general concept of something
> that is raised and caught is "exception" and since all the raise-able
> objects live in a module called "exceptions", it is confusing that
> "except Exception" will not catch all exceptions.
My thoughts
On Mon, 2006-03-20 at 11:43 -0800, Michael Chermside wrote:
> When you do, I'd like you to consider one change to the names. You are
> proposing this:
I'll keep this in mind, but won't comment further here for two reasons.
I want to think about it some more (you throw, er raise some good
points ;
Barry writes:
> I still believe in this, and I'm thankful for the support I've seen. It
> won't happen for Python 2.x, but I do plan on addressing this for Py3K.
When you do, I'd like you to consider one change to the names. You are
proposing this:
> Exception
> +- KeyboardInterrupt
> +- Generat
On Mon, 2006-03-20 at 08:18 -0800, Aahz wrote:
> -1 -- I occasionally use exceptions as a multi-loop break. That's a
> perfectly valid Python practice, those exceptions should inherit from
> Exception, and there should not be any warnings raised.
Exactly! But they're not errors, so "except Exce
On Sun, Mar 19, 2006, 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 o
On Sun, 2006-03-19 at 19:18 -0800, Guido van Rossum wrote:
> I have a problem with using Error as the focal point since so many
> exceptions (user-defined or otherwise) aren't errors.
I'm not sure that's totally true in practice. I think most user-defined
exceptions are actually errors. Ideall
On Sun, 2006-03-19 at 17:31 +1000, Nick Coghlan wrote:
> 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
On Sun, 2006-03-19 at 13:49 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
>
> > Exception
> > +- KeyboardInterrupt
> > +- GeneratorExit
> > +- SystemExit
> > +- StopIteration
> > +- Error
> > | +- ImportError
> > | +- (etc.)
> > |
> > +- Warning
> >+- UserWarning
> >+- (etc.)
>
> +42!
On Sat, 2006-03-18 at 15:37 -0800, Brett Cannon wrote:
> > 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
>
Raymond Hettinger wrote:
> 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 pr
[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
On 3/19/06, Greg Ewing <[EMAIL PROTECTED]> 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 Exceptio
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 pur
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
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
Nick Coghlan <[EMAIL PROTECTED]> 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 b
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 f
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.
>
> Al
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.
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 Exce
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.
Sys
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 clau
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 except
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 whe
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
___
P
On 3/18/06, Barry Warsaw <[EMAIL PROTECTED]> 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 k
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
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
> KeyboardInte
Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Exception
>> +- KeyboardInterrupt
>> +- GeneratorExit
>> +- SystemExit
>> +- StopIteration
>> +- Error
>>> +- ImportError
>>> +- (etc.)
>>>
>> +- Warning
>>+- UserWarning
>>+- (etc.)
>
> Cool! That's so far the clearest solution. An additional b
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 ta
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
> t
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
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).
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 i
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
45 matches
Mail list logo
