-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,
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
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:
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
for task in tasks:
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
proposing
[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
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
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
a manly
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! This is beautifully clear
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 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.
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 own errors.
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
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
+-
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 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 everyone's
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 raised.
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
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
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
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 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
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
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).
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
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 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
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 bonus is that
except
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
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 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 know
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
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
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
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.
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
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
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
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
39 matches
Mail list logo
