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 th
> "Willem" == Willem Broekema <[EMAIL PROTECTED]> writes:
Willem> 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
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' i
On 8/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:00 PM 8/2/2005 +1000, Nick Coghlan wrote:
[SNIP]
> Or maybe we
> should just make the primary hierarchy the way we want it to be, and only
> cross-link exceptions to StandardError that were previously under
> StandardError, i.e.:
>
>
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 occur
At 08:00 PM 8/2/2005 +1000, Nick Coghlan wrote:
>Python 2.4 Compatible Improved Exception Hierarchy v 0.1
>
>
>Exception
>+-- ControlFlowException (new)
> +-- GeneratorExit (new)
> +-- StopIteration
> +-- SystemExit
> +
At 04:13 PM 8/2/2005 +0900, Stephen J. Turnbull wrote:
>Now, somebody proposed:
>
>Raisable -+- Exception
> +- ...
> +- ControlFlowException -+- StopIteration
>+- KeyboardInterrupt
>
>As I wrote above, I see no use for that; I think that's wha
On Jul 31, 2005, at 12:49 PM, Phillip J. Eby wrote:
> I think you're ignoring the part where most exception handlers are
> already broken. At least adding CriticalException and
> ControlFlowException makes it possible to add this:
>
> try:
> ...
> except (CriticalException,Con
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 C
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
___
P
Nick Coghlan wrote:
> I have a Python 2.5 candidate hierarchy below, which uses dual inheritance to
> avoid breaking backward compatibility - any existing except clauses will
> catch
> all of the exceptions they used to catch. The only new inheritance introduced
> is to new exceptions, also avo
Stephen J. Turnbull wrote:
> Now, somebody proposed:
>
> Raisable -+- Exception
> +- ...
> +- ControlFlowException -+- StopIteration
>+- KeyboardInterrupt
>
> As I wrote above, I see no use for that
The use for it is :
try:
# do st
> "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. Conversel
At 12:25 PM 8/2/2005 +0900, Stephen J. Turnbull wrote:
> > "Willem" == Willem Broekema <[EMAIL PROTECTED]> writes:
>
> Willem> So, in short, Keyboard interrupts in Lisp are a
> Willem> serious-condition, not an error.
>
> Willem> (And what is labeled CriticalException in this discus
> "Willem" == Willem Broekema <[EMAIL PROTECTED]> writes:
Willem> So, in short, Keyboard interrupts in Lisp are a
Willem> serious-condition, not an error.
Willem> (And what is labeled CriticalException in this discussion,
Willem> has in serious-condition Lisp's counterpart.)
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 8/1/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > +-- Exception (formerly StandardError)
> > +-- AttributeError
> > +-- NameError
> > +-- UnboundLocalError
> > +-- RuntimeError
> > +-- NotImplementedError
>
> Time to wade in
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
sub
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
> "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.
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
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 progr
Nick Coghlan wrote:
> New Hierarchy
> =
>
> Raisable (formerly Exception)
> +-- CriticalException (new)
> +-- KeyboardInterrupt
> +-- MemoryError
> +-- SystemError
> +-- ControlFlowException (new)
> +-- GeneratorExit
> +-- StopIteration
> +-- SystemExit
>
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.
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 mak
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 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 '
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 'Err
On 7/30/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> 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.
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
> change
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 pro
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 see
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 KeyboardI
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.
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 sev
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
Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> On 7/30/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Brett Cannon <[EMAIL PROTECTED]> wrote:
> >
> > > > +-- Warning
> > > > +-- DeprecationWarning
> > > > +-- FutureWarning
> > > > +-- PendingDeprecationWarning
> > >
> > > Don
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
> >
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 pa
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
> > 10
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 DeprecationWarning inherit from
> > P
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
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 than my original? =)
It's like editing creative writi
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 appli
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
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
At 11:43 PM 7/30/2005 +1000, Nick Coghlan wrote:
>Here's a fairly minimal proposal, which is closer to the existing 2.4
>structure:
>
>New Hierarchy
>=
>
>Raisable (formerly Exception)
>+-- CriticalException (new)
> +-- KeyboardInterrupt
> +-- MemoryError
> +-- SystemErr
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 inherit
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 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
>
On Sat, Jul 30, 2005 at 06:41:51PM +1000, Nick Coghlan wrote:
> Brett Cannon wrote:
> > Don't forget this is Python 3.0; if it makes more sense we can break code.
>
> Or if he can be persuaded that ControlFlowException should exist as a peer of
> Exception and CriticalException. . .
>
> >>>+
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
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 t
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 this PEP is the reworking the hierarchy, requiring
>
Brett Cannon wrote:
> On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
>
>>Brett Cannon wrote:
>>
>>>New Hierarchy
>>>=
>>>
>>>Raisable (new; rename BaseException?)
>>>+-- CriticalException (new)
>>>+-- KeyboardInterrupt
>>>+-- MemoryError
>>>+-- SystemExit
>>>+-- S
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 it.
However, I'm even less sure StopIteration and Ge
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
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
On 7/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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 exce
On Friday 29 July 2005 23:07, Robert Brewer wrote:
> > +-- WeakReferenceError (rename for ReferenceError)
>
> This also has a LookupError feel to it.
I disagree.
LookupError is used when looking for an object within some containing object
according to some sort of key (dict key, index, et
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 expec
Brett Cannon wrote:
> New Hierarchy
> =
>
> Raisable (new; rename BaseException?)
> +-- CriticalException (new)
> +-- KeyboardInterrupt
> +-- MemoryError
> +-- SystemExit
> +-- SystemError (subclass SystemExit?)
I'd recommend not subclassing SystemExit--there are too m
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!
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
64 matches
Mail list logo
