Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 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 prefer the latter explanation. You're probably right. How does the following reasoning sound: SystemExit, GeneratorExit and StopIteration are all deliberately triggered by certain well-defined elements of normal application code. That is, only certain operations will ever result in a ControlFlowException being raised. KeyboardInterrupt is a better fit with MemoryError and SystemError - something that occurs unexpectedly, at an arbitary point during program execution. That is, a CriticalError may be raised when attempting to execute almost any operation. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] Pre-PEP: Exception Reorganization for Python 3.0
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 KeyboardInterrupt as a means to cause program halting. An interpreter could in principle recover from it and resume execution of the program. The behaviour of the current Python interpreters is that upon encountering an uncaught KeyboardInterrupt (as with any uncaught exception), computation is aborted and a backtrace printed. But that is not how it /must be/ as there might be alternative interpreters that upon encountering an uncaught KeyboardInterrupt will pause execution of the program, but then allow the user to either continue or abort execution, effectively not stopping but pausing the program. Because of this possible recovery, thinking of KeyboardInterrupt as "in order to abort the program, the user has caused a keyboard interrupt" is wrong; it should be more like just "the user has interrupted the computation" and whether or not the program is consequently aborted is not predefined. - 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
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 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. Actually, even in some such theoretical "Did you really mean that?" interpreter, the KeyboardInterrupt only gets raised if the interpreter determines that yes, the user really did want the program terminated. Otherwise, no exception is raised at all, and execution continues as usual. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] Pre-PEP: Exception Reorganization for Python 3.0
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 program should terminate, but may simply mean that the current operation should be stopped (as in many sorts of command interpreters). It's still *reasonable* to exit the Python interpreter if the application doesn't handle it; I can't think of any other reasonable default interpretation. (The interactive interpreter is simply an application that does handle the interrupt in an application-specific way.) So I think its reasonable to consider it a critical exception, because it's not predictable the way the control flow exceptions are; it's user-generated instead of application-generated. -Fred -- Fred L. Drake, Jr. ___ 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 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 involved with moving the KeyboardInterrupt, MemoryError and > SystemError out from under StandardError, and moving EOFError under > IOError. It seems to me that it *increases* the pain of transition. I do not see any reason why adding a new class above the current hierarchy causes any problems. However, changing the recommended base class for user-defined exceptions from "Exception" to "Error" will cause problems for *every* library. Moving KeyboardInterrupt, MemoryError, and SystemError out from under Exception will be a backwards compatibility issue, but that's the case in all proposals. Additionally, I predict the pain from doing that will be minor. In cases where apps want to catch *all* exceptions, they must already use "except:" instead of "except Exception:", as not all exceptions derive from Exception. And catching the above three in any circumstance other than when explicitly mentioned and when wanting to catch every exception is probably wrong. So moving them will probably not cause many programs to malfunction. I think the following could be done in Py2.5: a) add Raisable above Exception b) move KeyboardInterrupt, MemoryError, and SystemError somewhere under Raisable but not under Exception c) pending deprecation warning for "except:" and raising objects that aren't subclasses of "Raisable". d) (not really related, but while I'm at it...) Allow exceptions derived from object (with Raisable too, of course) For Py2.6: a) change pending deprecation warning above to deprecation warning. James ___ 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 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. > > I have no idea what you mean by "properly reflect increasing severity". > Should the more severe or less severe case be derived from the other? I > doubt there is a single answer that we can readily agree on. > > If DeprecationWarning and PendingDeprecationWarning need a class-hierarchy > relationship (and I think they do; it *is* reasonable for someone to deal > with them generically if they can reasonably want to deal with either), then > it seems they need a common base: > > +--AnyDeprecationWarning > +--DeprecationWarning > +--PendingDeprecationWarning > I can compromise and go with a common base class that both directly inherit from. -Brett ___ 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 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 don't know if I like this change in inheritance. 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 prefer the latter explanation. > >You're probably right. How does the following reasoning sound: > >SystemExit, GeneratorExit and StopIteration are all deliberately triggered by >certain well-defined elements of normal application code. That is, only >certain operations will ever result in a ControlFlowException being raised. > >KeyboardInterrupt is a better fit with MemoryError and SystemError - >something >that occurs unexpectedly, at an arbitary point during program execution. That >is, a CriticalError may be raised when attempting to execute almost any >operation. Ugh. A KeyboardInterrupt isn't an error, let alone a critical one. The fact that it occurs unexpectedly has nothing to do with it. A CriticalError needs different treatment than a KeyboardInterrupt for things like logging, notifications, etc. Heck, it needs different treatment just because a KeyboardInterrupt is something you can sanely recover from and gracefully shut down with. The odds of you recovering from an actual CriticalError are negligible. It's not the same thing, no matter what explanation you prefer. ;) ___ 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 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 don't know if I like this change in inheritance. 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 prefer the latter explanation. > > You're probably right. How does the following reasoning sound: > > SystemExit, GeneratorExit and StopIteration are all deliberately triggered by > certain well-defined elements of normal application code. That is, only > certain operations will ever result in a ControlFlowException being raised. > > KeyboardInterrupt is a better fit with MemoryError and SystemError - something > that occurs unexpectedly, at an arbitary point during program execution. That > is, a CriticalError may be raised when attempting to execute almost any > operation. > 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. -Brett ___ 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 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 > > occurred? > > 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. > The behaviour of the current Python interpreters is that upon > encountering an uncaught KeyboardInterrupt (as with any uncaught > exception), computation is aborted and a backtrace printed. But that > is not how it /must be/ as there might be alternative interpreters > that upon encountering an uncaught KeyboardInterrupt will pause > execution of the program, but then allow the user to either continue > or abort execution, effectively not stopping but pausing the program. > > Because of this possible recovery, thinking of KeyboardInterrupt as > "in order to abort the program, the user has caused a keyboard > interrupt" is wrong; it should be more like just "the user has > interrupted the computation" and whether or not the program is > consequently aborted is not predefined. > But interpreter termination is not guaranteed for any exception, even SystemError since it can be caught and not re-raised. Plus the common use of hittting ctrl-c while an app is running is to kill it, not to pause the execution. But it doesn't sound like you are arguing against putting KeyboardInterrupt under CriticalException, but just the explanation I gave, right? -Brett ___ 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 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 makes it a child of Raisable, not Error. -Fred -- Fred L. Drake, Jr. ___ 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: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 - the only tricky parts are > > semantic > > changes involved with moving the KeyboardInterrupt, MemoryError and > > SystemError out from under StandardError, and moving EOFError under > > IOError. > >It seems to me that it *increases* the pain of transition. >I do not see any reason why adding a new class above the current >hierarchy causes any problems. However, changing the recommended base >class for user-defined exceptions from "Exception" to "Error" will >cause problems for *every* library. 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,ControlFlowException): raise except: ... This isn't great, I admit, but at least it would actually *work*. I also don't see how changing the recommended base class from Exception to Error causes *problems* for every library. Sure, it forces them to move (eventually!), but it's a trivial change, and makes it *possible* to do the right thing with exceptions (e.g. except Error:) as soon as all the libraries you depend on have moved to using Error. >Moving KeyboardInterrupt, MemoryError, and SystemError out from under >Exception will be a backwards compatibility issue, but that's the >case in all proposals. Actually, in my tweak of Nick's proposal they're still Exception subclasses, so nothing breaks. >Additionally, I predict the pain from doing >that will be minor. In cases where apps want to catch *all* >exceptions, they must already use "except:" instead of "except >Exception:", as not all exceptions derive from Exception. And >catching the above three in any circumstance other than when >explicitly mentioned and when wanting to catch every exception is >probably wrong. So moving them will probably not cause many programs >to malfunction. In which case, maybe we should just implement Nick's full proposal, since the only thing that it would break is code that uses "except Exception:" to catch SystemExit or StopIteration. ___ 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] Extension of struct to handle non byte aligned values?
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. As an
example, I'd like to be able to grab just a single bit from a byte
string, and I'd also like to modify, for example, 13 bits. These are
all reasonable quantities in an IPv4 packet. I have looked at doing
this all in Python within my own classes but I believe this is a
general extension that would be good for the struct module. I could
also write a new module, bitstruct, to do this but that seems silly.
I did not find anything out there that handles this case, so if I
missed that then please let me know.
My proposal would be for a new format character, 'z', which is
followed by a position in bits from 0 to 31 so that we get either a
byte, halfword, or longword based byte string back and then an
optional 'r' (for run length, and because 'l' and 's' are already
used) followed by a number of bits. The default length is 1 bit. I
believe this is sufficient for most packet protocols I know of
because, for the most part, protocols try to be 32 or 64bit aligned.
This would ALWAYS unpack into an int type. So, you would see this:
bytestring = pack("z0r3z3r13", flags, fragment)
this would pack the flags and fragment offset in a packet at bits 0-3
and 3-13 respectively and return a 2 byte byte-string.
header_length = unpack("z4r4", packet.bytes)
would retrieve the header length from the packet, which is from bits 4
through 8.
Thoughts?
Thanks,
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
Nick Coghlan wrote: > New Hierarchy > = > > Raisable (formerly Exception) > +-- CriticalException (new) > +-- KeyboardInterrupt > +-- MemoryError > +-- SystemError > +-- ControlFlowException (new) > +-- GeneratorExit > +-- StopIteration > +-- SystemExit > +-- Exception (formerly StandardError) If CriticalException and ControlFlowException are to be siblings of Exception rather than subclasses of it, they should be renamed so that they don't end with "Exception". Otherwise there will be a confusing mismatch between the actual inheritance hierarchy and the one suggested by the naming. Also, I'm not entirely happy about Exception no longer being at the top, because so far the word "exception" in relation to Python has invariably meant "anything that can be raised". This terminology is even embedded in the syntax with the try-except statement. Changing this could to lead to some awkward circumlocutions in the documentation and confusion in discussions. -- 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] PEP: Migrating the Python CVS to Subversion
> "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. -- 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
