Brett Cannon wrote:
On 8/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
It seems to me that multiple inheritance is definitely the right idea,
though. That way, we can get the hierarchy we really want with only a
minimum of boilerplate in pre-3.0 to make it actually work.
Yeah. I think name
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip You just said, Unhandled, KeyboardInterrupt means...
Phillip If the program doesn't *want* to handle
Phillip KeyboardInterrupt, then it obviously *isn't* critical,
Phillip because it doesn't care. Conversely, if it
On Tue, 2005-08-02 at 11:00, Nick Coghlan wrote:
With this hierarchy, the recommended parent class for application errors
becomes Error, ...
And presumably Error could also be the recommended exception for
quick'n'dirty scripts.
Mark Russell
___
On Aug 2, 2005, at 12:31 AM, Phillip J. Eby wrote:
If you think that a KeyboardInterrupt is an error, then it's an
indication
that Python's documentation and the current exception class
hierarchy has
failed to educate you sufficiently, and that we *really* need to add a
class like
At 10:53 AM 8/2/2005 -0400, James Y Knight wrote:
No... KeyboardInterrupt (just like other asynchronous exceptions)
really should be treated as a critical error. Doing anything other
than killing your process off after receiving it is just inviting
disaster. Because the exception can have occurred
On 8/2/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
I don't see it that way. Rather, Raisable is the closest equivalent
to serious-condition, and CriticalException is an intermediate
class that has no counterpart in Lisp usage.
That would imply that all raisables are 'serious' in the Lisp
On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote:
On 7/31/05, Willem Broekema [EMAIL PROTECTED] wrote:
I does not seem right to me to think of KeyboardInterrupt as a means
to cause program halting. An interpreter could in principle recover
from it and resume execution of the program.
Willem Broekema [EMAIL PROTECTED] writes:
I realize it's major work to add recovery features to the CPython
interpreter, so I don't think CPython will have anything like it soon
and therefore also Python-the-language will not. Instead, my reason
for mentioning this is to get the _concept_ of
Willem == Willem Broekema [EMAIL PROTECTED] writes:
Willem I hope the above makes the way I'm thinking more clear.
Willem Like Phillip J. Eby, I think that labeling
Willem KeyboardInterrupt a CriticalException seems wrong; it is
Willem not an error and not critical.
Uh,
On 8/1/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
Uh, according to your example in Common LISP it is indeed an error,
I think you are referring to the first word of this line:
Error: Received signal number 2 (Keyboard interrupt) [condition type:
INTERRUPT-SIGNAL]
Well, that refers to
Nick Coghlan wrote:
+-- Exception (formerly StandardError)
+-- AttributeError
+-- NameError
+-- UnboundLocalError
+-- RuntimeError
+-- NotImplementedError
Time to wade in ...
I've actually been wondering if NotImplementedError should actually be a
subclass
On 8/1/05, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
+-- Exception (formerly StandardError)
+-- AttributeError
+-- NameError
+-- UnboundLocalError
+-- RuntimeError
+-- NotImplementedError
Time to wade in ...
I've
Brett Cannon wrote:
The problem with subclassing NotImplementedError is you need to
remember it is used to signal that a magic method does not work for a
specific type and thus should try the __r*__ version.
No, that's done by *returning* NotImplemented, not by
raising an exception at all.
On Saturday 30 July 2005 22:20, Brett Cannon wrote:
True, but the hierarchy should still properly reflect increasing
severity in my opinion. I am going to push for this; we will see if I
get pushed back enough to not do it.
I have no idea what you mean by properly reflect increasing
Brett Cannon wrote:
Notice that I've classified KeyboardInterrupt as user-initiated control flow
and put it under ControlFlowException above. This means that everything under
CriticalError and Error actually ends with the word 'Error'.
I don't know if I like this change in inheritance. While
On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote:
While we do tend to use KeyboardInterrupt as a way to kill a
program, is that really control flow, or a critical exception
that the program needs to stop because an serious event
occurred?
I does not seem right to me to think of
Willem Broekema wrote:
On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote:
While we do tend to use KeyboardInterrupt as a way to kill a
program, is that really control flow, or a critical exception
that the program needs to stop because an serious event
occurred?
I does not seem right to me
On Sunday 31 July 2005 06:36, Willem Broekema wrote:
I does not seem right to me to think of KeyboardInterrupt as a means
to cause program halting. An interpreter could in principle recover
from it and resume execution of the program.
Somewhat. An interrupt may well not mean that the
On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
I wouldn't mind using Exception/Error instead of Raisable/Exception
- and it
seriously reduces the pain of making this transition. Indeed, most
of it
becomes doable within the 2.x series - the only tricky parts are
semantic
changes
At 05:05 PM 7/31/2005 +1000, Nick Coghlan wrote:
Brett Cannon wrote:
Notice that I've classified KeyboardInterrupt as user-initiated control
flow
and put it under ControlFlowException above. This means that everything
under
CriticalError and Error actually ends with the word 'Error'.
I
On 7/31/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Notice that I've classified KeyboardInterrupt as user-initiated control flow
and put it under ControlFlowException above. This means that everything
under
CriticalError and Error actually ends with the word 'Error'.
I
On 7/31/05, Willem Broekema [EMAIL PROTECTED] wrote:
On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote:
While we do tend to use KeyboardInterrupt as a way to kill a
program, is that really control flow, or a critical exception
that the program needs to stop because an serious event
On Sunday 31 July 2005 12:17, Brett Cannon wrote:
Yeah, those explanations work for me. I think I am going to have to
write an explanation for every exception so its usage is clear.
That said, I agree with Phillip; a KeyboardInterrupt isn't an error, it's
asynchronous user input. That
At 12:12 PM 7/31/2005 -0400, James Y Knight wrote:
On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
I wouldn't mind using Exception/Error instead of Raisable/Exception
- and it
seriously reduces the pain of making this transition. Indeed, most
of it
becomes doable within the 2.x series -
Nick Coghlan wrote:
New Hierarchy
=
Raisable (formerly Exception)
+-- CriticalException (new)
+-- KeyboardInterrupt
+-- MemoryError
+-- SystemError
+-- ControlFlowException (new)
+-- GeneratorExit
+-- StopIteration
+-- SystemExit
+--
On 7/29/05, Robert Brewer [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
New Hierarchy
=
Raisable (new; rename BaseException?)
+-- CriticalException (new)
+-- KeyboardInterrupt
+-- MemoryError
+-- SystemExit
+-- SystemError (subclass SystemExit?)
I'd
OK, I withdraw the suggestion of the subclassing of SystemError by SystemExit.
-Brett
On 7/29/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/29/05, Robert Brewer [EMAIL PROTECTED] wrote:
+-- SystemExit
+-- SystemError (subclass SystemExit?)
I'd recommend not subclassing
On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:
I'd recommend not subclassing SystemExit--there are too many programs
out there which expect the argument (e.g. sys.exit(3)) to mean
something
specific, but that expectation doesn't apply at all to SystemError.
Yes please make note of this
M.-A. Lemburg wrote:
The reason for my -1 on the renaming and reordering is
that it would completely break compatibility of Python 2.x
applications with Python 3. Furthermore, there would be next to
no chance of writing new applications that run in Python 3
and 2, so you have breakage in both
On Sat, Jul 30, 2005, Nick Coghlan wrote:
I think the problems with this can be minimised by avoiding making
changes we don't need to. I think only a few changes are needed to get
a significantly cleaner structure.
Here's a fairly minimal proposal, which is closer to the existing 2.4
Nick Coghlan wrote:
Here's a fairly minimal proposal, which is closer to the existing 2.4
structure:
New Hierarchy
...
I also like this version.
--
Brian Beck
Adventurer of the First Order
___
Python-Dev mailing list
Python-Dev@python.org
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
+-- ControlFlowException (new)
While I like the idea of ControlFlowException as the one obvious way to
break out of multiple nested loops, I'm not convinced StopIteration and
GeneratorExit should be inheriting from
On 7/30/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Well, it has been discussed at multiple times in the past and I have
promised to write this PEP several times, so I finally found enough
time to write a PEP on reorganizing exceptions for Python 3.0 .
Key points in
On 7/30/05, James Y Knight [EMAIL PROTECTED] wrote:
On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:
I'd recommend not subclassing SystemExit--there are too many programs
out there which expect the argument (e.g. sys.exit(3)) to mean
something
specific, but that expectation doesn't
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
M.-A. Lemburg wrote:
The reason for my -1 on the renaming and reordering is
that it would completely break compatibility of Python 2.x
applications with Python 3. Furthermore, there would be next to
no chance of writing new applications
Phillip J. Eby wrote:
I like this a lot, and a good bit of it could actually be done in 2.5,
apart from the Exception/StandardError move, assuming also that the
renamed errors were also available under their old names. We could
probably go so far as to add Raisable to the hierarchy, but I
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Nick, are you going go start subbing in for Tim when he is busy and
take my work that I spent hours on, come up with an alternative that
took 10 minutes, and have everyone end up loving your newfangled idea
10x more
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
[SNIP]
+-- RuntimeError
I still don't like the name.
I'm not that fond of it either - but as the builtin exception most likely to
be used (abused?) by user code, I expect changing its name would be more pain
than
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
I like this a lot, and a good bit of it could actually be done in 2.5,
apart from the Exception/StandardError move, assuming also that the
renamed errors were also available under their old names. We could
probably
Brett Cannon [EMAIL PROTECTED] wrote:
On 7/30/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Brett Cannon [EMAIL PROTECTED] wrote:
+-- Warning
+-- DeprecationWarning
+-- FutureWarning
+-- PendingDeprecationWarning
Don't like the idea of having
On Sat, Jul 30, 2005, Brett Cannon wrote:
My view of Python 3.0 was that backwards-compatibility would not be a
gimme in anyway. I personally am willing to break stuff in the name
of clarity, which is the point of this whole endeavour. While I am
willing to back off on some the proposed
Well, it has been discussed at multiple times in the past and I have
promised to write this PEP several times, so I finally found enough
time to write a PEP on reorganizing exceptions for Python 3.0 .
Key points in this PEP is the reworking the hierarchy, requiring
anything raised to inherit from
On 7/29/05, Brett Cannon [EMAIL PROTECTED] wrote:
Well, it has been discussed at multiple times in the past and I have
promised to write this PEP several times, so I finally found enough
time to write a PEP on reorganizing exceptions for Python 3.0 .
Thanks for getting this ball rolling!
(I
On 7/29/05, Robert Brewer [EMAIL PROTECTED] wrote:
+-- SystemExit
+-- SystemError (subclass SystemExit?)
I'd recommend not subclassing SystemExit--there are too many programs
out there which expect the argument (e.g. sys.exit(3)) to mean something
specific, but that expectation
44 matches
Mail list logo
