Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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. > > > > Same goes for MemoryError as well, but you probably don't want to > catch that exception either. Well, an possible scenario is that if allocation of memory fails, then the interpreter (not the Python program in it) can detect that it is not caught explicitly and print possible ways of execution, like "try the allocation again" or "abort the program", letting the user determine how to proceed. Although in this case immediately retrying the allocation will fail again, so the user has to have a way to free some objects in the meantime. 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 recoveries across. I think including (hypothetical, for now) recovery features in a discussion about exceptions is valuable, because that influences whether one thinks a label like "critical" for an exception is appropriate. I'm working on an implementation of Python in Common Lisp. The CL condition system offers recovery features, so this implementation could, too. Instead of the interpreter handling the interrupt in an application-specific way, as Fred said, the interpreter could handle the interrupt by leaving the choice to the user. Concretely, this is how KeyboardInterrupt is handled by a CL interpreter, and thus also how a Python interpreter could handle it: (defun foo () (loop for i from 0 do (format t "~A " i))) (foo) => 0 1 2 3 Error: Received signal number 2 (Keyboard interrupt) [condition type: INTERRUPT-SIGNAL] Restart actions (select using :continue): 0: continue computation 1: Return to Top Level (an "abort" restart). 2: Abort entirely from this process. :continue 0 => 4 5 6 ... > But it doesn't sound like you are arguing against putting > KeyboardInterrupt under CriticalException, but just the explanation I > gave, right? I hope the above makes the way I'm thinking more clear. Like Phillip J. Eby, I think that labeling KeyboardInterrupt a CriticalException seems wrong; it is not an error and not critical. - Willem ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension of struct to handle non byte aligned values?
"George V. Neville-Neil" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm attempting to write a Packet class, and a few other classes for
> use in writing protocol conformance tests. For the most part this is
> going well except that I'd like to be able to pack and unpack byte
> strings with values that are not 8 bit based quantities.
[...]
> Thoughts?
Well, the main thing that comes to mind is that I wouldn't regard the
struct interface as being something totally wonderful and perfect.
I am aware of a few attempts to make up a better interface, such as
ctypes and Bob's rather similar looking ptypes from macholib:
http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
and various silly unreleased things I've done. They all work on the
basic idea of a class schema that describes the binary structure, eg:
class Sound(Message):
code = 0x06
layout = [('mask', BYTE()),
('vol', CDI(1, SDI(BYTE(), 1/255.0), 1.0)),
('attenuation', CDI(2, SDI(BYTE(), 1/64.0), 1.0)),
('entitychan', SHORT()),
('soundnum', BYTE()),
('origin', COORD()*3)]
You may want to do something similar (presumably the struct module or
some other c stuff would be under the hood somewhere).
I don't really see a need to change CPython here, unless some general
binary parsing scheme becomes best-of-breed and a candidate for stdlib
inclusion.
Cheers,
mwh
PS: This is probably more comp.lang.python material.
--
The use of COBOL cripples the mind; its teaching should, therefore,
be regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 recoveries across. I > think including (hypothetical, for now) recovery features in a > discussion about exceptions is valuable, because that influences > whether one thinks a label like "critical" for an exception is > appropriate. Heh, I talked about this at EuroPython... http://starship.python.net/crew/mwh/recexc.pdf The technical barriers are insignificant, really. Cheers, mwh -- Our Constitution never promised us a good or efficient government, just a representative one. And that's what we got. -- http://www.advogato.org/person/mrorganic/diary.html?start=109 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
> "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, according to your example in Common LISP it is indeed an error, and if an unhandled signal whose intended interpretation is "drop the gun and put your hands on your head!" isn't critical, what is? I didn't miss your point, but I don't see a good reason to oppose that label based on the usual definitions of the words or Common LISP usage, either. It seems to me the relevant question is "is it likely that catching KeyboardInterrupt with 'except Exception:' will get sane behavior from a generic user-defined handler?" I think not; usually you'd like generic error recovery to _not_ bother the user, but KeyboardInterrupt sort of demands interaction with the user, no? So you're going to need a separate routine for KeyboardInterrupt, anyway. I expect that's going to be the normal case. So I would say KeyboardInterrupt should derive from CriticalException, not from Exception. I definitely agree that implementing recovery features is a good idea, and in interactive operation (or with an option to the interpreter), to allow for such recovery in the interpreter itself. For example, the interpreter could keep a small nest egg of memory for the purpose of interacting with the user; this would be harder for a program to do. And in many quickie scripts it would be convenient if the interpreter would drop into interactive mode, not die, if the program encounters a critical exception. But it's still a critical exception to the program written in Python, even if it's easy for the user to handle and the interpreter provides the capability to pass the buck to the user. The program has completely lost control! -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Syscall Proxying in Python
Hi, We embbeded Python 2.0.1 in our product a few years ago and we'd like to upgrade to Python 2.4.1. This was not a simple task, because we needed to execute syscalls on a remote host. We modified Python's source code in severall places to call our own versions of some functions. For example, instead of calling fopen(...), the source code was modified to call remote_fopen(...), and the same was done with other libc functions. Socket functions where hooked too (we modified socket.c), Windows Registry functions, etc.. There are some syscalls that we don't want to execute remotely. For example when importing a module. That has to be local, and we didn't modified that. Python scripts are executed locally, but syscalls are executed on a remote host, thus giving the illusion that the script is executing on the remote host. As I said before, we're in the process of upgrading and we don't want to make such unmaintainable changes to Python's code. We'd like to make as few changes as possible. The aproach we're trying this time is far less intrusive: We'd like to link Python with special libraries that override those functions that we want to execute remotely. This way the only code that has to be changed is the one that has to be executed locally. I wrote this mail to ask you guys for any useful advice in making this changes to Python's core. The only places I figure out right now that have to execute locally all the time are import.c and pythonrun.c, but I'm not sure at all. Maybe you guys figure out another way to achieve what we need. Thanks in advance. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES Florida 141 - 2º cuerpo - 7º piso C1005AAC Buenos Aires - Argentina Tel/Fax: (54 11) 5032-CORE (2673) http://www.corest.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On Sun, 2005-07-31 at 23:54, Stephen J. Turnbull wrote: > > "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes: > > BAW> So are you saying that moving to svn will let us do more long > BAW> lived branches? Yay! > > Yes, but you still have to be disciplined about it. svn is not much > better than cvs about detecting and ignoring spurious conflicts due to > code that gets merged from branch A to branch B, then back to branch > A. Unrestricted cherry-picking is still out. Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge properly. All the other cool stuff like renames etc is kinda undone by that. For a definition of properly, see; http://prcs.sourceforge.net/merge.html This is why I don't bother migrating any existing CVS projects to SVN; the benefits don't yet outweigh the pain of migrating. For new projects sure, SVN is a better choice than CVS. -- Donovan Baarda <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syscall Proxying in Python
On Mon, 2005-08-01 at 10:36, Gabriel Becedillas wrote: > Hi, > We embbeded Python 2.0.1 in our product a few years ago and we'd like to > upgrade to Python 2.4.1. This was not a simple task, because we needed > to execute syscalls on a remote host. We modified Python's source code > in severall places to call our own versions of some functions. For > example, instead of calling fopen(...), the source code was modified to > call remote_fopen(...), and the same was done with other libc functions. > Socket functions where hooked too (we modified socket.c), Windows > Registry functions, etc.. Wow... you guys sure did it the hard way. If you had done it at the Python level, you would have had a much easier time of both implementing and updating it. As an example, have a look at my osVFS stuff. This is a replacement for the os module and open() that tricks Python into using a virtual file system; http://minkirri.apana.org.au/~abo/projects/osVFS -- Donovan Baarda <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 the fact that it was raised with (error ...). It
says nothing about the type of a Keyboad interrupt condition. (The
function 'error' vs 'signal' mark the distinction between raising
conditions that must be handled otherwise you'll end up in the
debugger, and conditions that when not handled are silently ignored.)
The CL ANSI standard does not define what kind of condition a Keyboard
interrupt is, so the implementations have to make that decision.
Although this implementation (Allegro CL) has currently defined it as
a subclass of 'error', I'm told it should have been a
'serious-condition' instead ('error' is a subclass of
'serious-condition', which is a subclass of 'condition'), precisely
because forms like ignore-errors, like a bare except in Python, will
catch it right now when they shouldn't. I assume most of the other
Lisp implementations have already defined it as serious-condition.
So, in short, Keyboard interrupts in Lisp are a serious-condition, not an error.
(And what is labeled CriticalException in this discussion, has in
serious-condition Lisp's counterpart.)
> and if an unhandled signal whose intended interpretation is "drop the
> gun and put your hands on your head!" isn't critical, what is?
Eh, are you serious?
> I didn't miss your point, but I don't see a good reason to oppose that
> label based on the usual definitions of the words or Common LISP
> usage, either.
Well, I'm not opposed to KeyboardInterrupt being in a class that's not
a subclass of 'Exception', when the latter is the class used in a bare
'except'. But when CriticalException, despite its name, is not a
subclass of Exception, that is a bit strange. I'd prefer the
'condition' and 'error' terminology, and to label a keyboard interrupt
a condition, not any kind of exception or error.
> It seems to me the relevant question is "is it likely that catching
> KeyboardInterrupt with 'except Exception:' will get sane behavior from
> a generic user-defined handler?"
I agree with you that it should not be caught in a bare 'except' (or
an 'except Exception', when that is equivalent).
- Willem
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 of AttributeError. Everywhere I can think of where I would want to catch NotImplementedError, I would also want to catch AttributeError. My main question is whether I would want the reverse to also be true - anywhere I want to catch AttributeError, I would want to catch NotImplementedError. Perhaps instead it should be the other way around - AttributeError inherits from NotImplementedError. This does make some kind of sense - the attribute hasn't been implemented. Both seem to have some advantages, but neither really feels right to me. Thoughts? Anyway, I came to this via another thing - NotImplementedError doesn't play very well with super(). In many ways it's worse to call super().method() that raises NotImplementedError than super().method() where the attribute doesn't exist. In both cases, the class calling super() needs to know whether or not it's at the end of the MRO for that method - possible to find out in most cases that would raise AttributeError, but impossible for a method that raises NotImplementedError. The only way I can think of to deal with this is to do a try: except (AttributeError, NotImplementedError) around every super() attribute call. This seems bad. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 actually been wondering if NotImplementedError should actually be a > subclass of AttributeError. > > Everywhere I can think of where I would want to catch > NotImplementedError, I would also want to catch AttributeError. My main > question is whether I would want the reverse to also be true - anywhere > I want to catch AttributeError, I would want to catch > NotImplementedError. > > Perhaps instead it should be the other way around - AttributeError > inherits from NotImplementedError. This does make some kind of sense - > the attribute hasn't been implemented. > > Both seem to have some advantages, but neither really feels right to me. > Thoughts? 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. That is not a case, I feel, that has anything to do with attributes but implementation support. I am not going to subclass NotImplementedError unless a huge push for it in a very specific direction. -Brett (who is waiting on a PEP number...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On Thursday 28 July 2005 13:00, Martin v. Löwis wrote: > I'd like to see the Python source be stored in Subversion instead > of CVS, I'm +1 on this, assuming we use the fsfs backend, and not the berkeley DB one. I'm -1 if we're using the bdb backend (I've had nothing but pain from it). > CVS has a number of limitations that have been elimintation by > Subversion. For the development of Python, the most notable improvements > are: > - ability to rename files and directories, and to remove directories, > while keeping the history of these files. > - support for change sets (sets of correlated changes to multiple > files) through global revision numbers. > - support for offline diffs, which is useful when creating patches. - tagging for releases will no longer cause the release manager to experience fits of burning rage (personal record was something like 1h45m for 'cvs tag' to finish, from memory). My only concern is that we have sufficient volunteers to manage the system. I'm happy to be one of these, but that's assuming we have other people also volunteering. . . Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
> "Donovan" == Donovan Baarda <[EMAIL PROTECTED]> writes: Donovan> Yeah. IMHO the sadest thing about SVN is it doesn't do Donovan> branch/merge properly. All the other cool stuff like Donovan> renames etc is kinda undone by that. [...] This is why Donovan> I don't bother migrating any existing CVS projects to Donovan> SVN; the benefits don't yet outweigh the pain of Donovan> migrating. FWIW, XEmacs just had this discussion, and we basically came to the conclusion that for a multi-developer project it's _definitely_ worth the effort if it can be done by cvs2svn (which for us it probably can't, due to some black magic we did on the CVS repository a few years ago :-( ). For the record, I was opposed for exactly the reason you give, but changed my mind. The point is that with several developers there's almost surely someone enthusiastic enough about svn to bear the burden of fooling with the script for a couple of hours to see if it works, a fascist policy about migrating account names makes that almost trivial, and after that it's all gravy: the administration does not look any worse, the security issues are similar, and the change is likely to incite only a few people to press for account name changes after the move. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
> "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.) 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. >> and if an unhandled signal whose intended interpretation is >> "drop the gun and put your hands on your head!" isn't critical, >> what is? Willem> Eh, are you serious? Yes. Unhandled, KeyboardInterrupt means that the user has forcibly taken control away from the program without giving it a chance to preserve state, finish responding to (realtime) external conditions, or even activate vacation(1), and the program is entirely at the mercy of the user. Usually, the program then proceeds to die without dignity. If it's a realtime application, killing it is probably the only merciful thing to do. If you were the program, wouldn't you consider that critical? Willem> But when CriticalException, despite its name, is not a Willem> subclass of Exception, that is a bit strange. Granted. It doesn't bother me, but since it bothers both you and Philip Eby, I concede the point; we should find a better name (or not bother with such a class, see below). Willem> I'd prefer the 'condition' and 'error' terminology, and to Willem> label a keyboard interrupt a condition, not any kind of Willem> exception or error. Now, that does bother me. Anything we will not permit a program to ignore with a bare "except: pass" if it so chooses had better be more serious than merely a "condition". Also, to me a "condition" is something that I poll for, it does not interrupt me. To me, a condition (even a serious one) is precisely the kind of thing that I should be able to ignore with a bare except! Your description of the CL hierarchy makes me wonder if there's any benefit to having a class between Raisable and KeyboardInterrupt. Unlike SystemShutdown or PowerFailure, KeyboardInterrupt does imply presence of a user demanding attention; I suppose that warrants special treatment. On the other hand, I don't see a need for a class whose members share only the property that they are not catchable with a bare except, leading to Raisable -+- Exception +- KeyboardInterrupt +- SystemShutdown +- PowerFailure +- (etc) or even Exception -+- CatchableException +- KeyboardInterrupt +- SystemShutdown +- PowerFailure +- (etc) The latter is my mental model, and would work well with bare excepts. It also would encourage the programmer to think about whether an Exception should be catchable or is a special case, but I don't think that's really helpful except for Python developers, who presumably would be aware of the issues. The former would be a compromise to allow "except Exception" to be a natural idiom, which I prefer to bare excepts on stylistic grounds. On balance, that's what I advocate. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
At Mon, 01 Aug 2005 10:52:03 -0700, Donovan Baarda wrote: > > On Sun, 2005-07-31 at 23:54, Stephen J. Turnbull wrote: > > > "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes: > > > > BAW> So are you saying that moving to svn will let us do more long > > BAW> lived branches? Yay! > > > > Yes, but you still have to be disciplined about it. svn is not much > > better than cvs about detecting and ignoring spurious conflicts due to > > code that gets merged from branch A to branch B, then back to branch > > A. Unrestricted cherry-picking is still out. > > Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge > properly. All the other cool stuff like renames etc is kinda undone by > that. For a definition of properly, see; > > http://prcs.sourceforge.net/merge.html > > This is why I don't bother migrating any existing CVS projects to SVN; > the benefits don't yet outweigh the pain of migrating. For new projects > sure, SVN is a better choice than CVS. Since Python is Open Source are you looking at Per Force which you can use for free and seems to be a happy medium between something like CVS and something horrific like Clear Case? Later, George ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 discussion, > Willem> has in serious-condition Lisp's counterpart.) > >I don't see it that way. Rather, "Raisable" is the closest equivalent >to "serious-condition", I don't think that Lisp's idea of an exception hierarchy has much bearing here. > >> and if an unhandled signal whose intended interpretation is > >> "drop the gun and put your hands on your head!" isn't critical, > >> what is? > > Willem> Eh, are you serious? > >Yes. Unhandled, KeyboardInterrupt means that the user has forcibly >taken control away from the program without giving it a chance to >preserve state, finish responding to (realtime) external conditions, >or even activate vacation(1), and the program is entirely at the mercy >of the user. Usually, the program then proceeds to die without >dignity. If it's a realtime application, killing it is probably the >only merciful thing to do. > >If you were the program, wouldn't you consider that critical? You just said, "Unhandled, KeyboardInterrupt means..." If the program doesn't *want* to handle KeyboardInterrupt, then it obviously *isn't* critical, because it doesn't care. Conversely, if it *does* handle KeyboardInterrupt, then once again, it's not critical by your definition. So, clearly, KeyboardInterrupt is thus *not* critical, and doesn't belong in the CriticalException hierarchy. Note, by the way, that Python programs can disable a KeyboardInterrupt from ever occurring in the first place, whereas none of the other CriticalException classes can be "disabled" because they're actually *error* conditions, while KeyboardInterrupt is just an asynchronous notification - for control flow purposes. Ergo, it's a control flow exception. (Similarly, a Python program can avoid raising any of the other control flow errors; they are by and large optional features.) > Willem> I'd prefer the 'condition' and 'error' terminology, and to > Willem> label a keyboard interrupt a condition, not any kind of > Willem> exception or error. > >Now, that does bother me. Anything we will not permit a program >to ignore with a bare "except: pass" if it so chooses had better be >more serious than merely a "condition". Also, to me a "condition" is >something that I poll for, it does not interrupt me. To me, a >condition (even a serious one) is precisely the kind of thing that I >should be able to ignore with a bare except! On the contrary, it is control-flow exceptions that bare except clauses are most harmful to: StopIteration, SystemExit, and... you guessed it... KeyboardInterrupt. An exception that's being used for control flow is precisely the kind of thing you don't want anything but an explicit except clause to catch. Whether critical errors should also pass bare except clauses is a distinct issue, one which KeyboardInterrupt really doesn't enter into. 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 ControlFlowException into the hierarchy to help make sure that other people don't end up sharing your misunderstanding. ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
