Mailman 3 August 2005 - Python-Dev

String exceptions in Python source
by Edward C. Jones 04 Aug '05

04 Aug '05

/usr/local/src/Python-2.4.1/Lib/SimpleXMLRPCServer.py: raise 'bad method' /usr/local/src/Python-2.4.1/Demo/classes/bitvec.py: raise 'FATAL', '(param, l) = %r' % ((param, l),) /usr/local/src/Python-2.4.1/Lib/plat-mac/FrameWork.py: raise 'Unsupported in MachoPython' /usr/local/src/Python-2.4.1/Lib/plat-mac/FrameWork.py: raise 'Can only delete last item of a menu' /usr/local/src/Python-2.4.1/Lib/plat-mac/MiniAEFrame.py: raise 'Cannot happen: AE callback without handler', (_class, _type) /usr/local/src/Python-2.4.1/Lib/plat-mac/PixMapWrapper.py: raise 'UseErr', "don't assign to .baseAddr -- assign to .data instead" /usr/local/src/Python-2.4.1/Lib/plat-mac/argvemulator.py: raise 'Cannot happen: AE callback without handler', (_class, _type) /usr/local/src/Python-2.4.1/Mac/Modules/waste/wastescan.py: raise 'Error: not found: %s', WASTEDIR /usr/local/src/Python-2.4.1/Mac/Tools/IDE/PyDebugger.py: raise 'spam' (3 times) /usr/local/src/Python-2.4.1/Mac/Tools/macfreeze/macfreeze.py: raise 'unknown gentype', gentype /usr/local/src/Python-2.4.1/Mac/Tools/macfreeze/macfreezegui.py: raise 'Error in gentype', gentype

1 0

PEP-343 - Context Managment variant
by falcon 04 Aug '05

04 Aug '05

I know I came after the battle. And I have just another sight on context managment. Simple Context Managment may look in Python 2.4.1 like this: Synhronized example: def Synhronised(lock,func): lock.acquire() try: func() finally: lock.release() .... lock=Lock() def Some(): local_var1=x local_var2=y local_var3=Z def Work(): global local_var3 local_var3=Here_I_work(local_var1,local_var2,local_var3) Synhronised(lock,Work) return asd(local_var3) FileOpenClose Example: def FileOpenClose(name,mode,func): f=file(name,mode) try: func(f) finally: f.close() .... def Another(name): local_var1=x local_var2=y local_var3=None def Work(f): global local_var3 local_var3=[[x,y(i)] for i in f] FileOpenClose(name,'r',Work) return local_var3 It was complicated because : 1. We must declare closure (local function) before using it 2. We must declare local vars, to which we wish assign in "global" statement 3. We cannot create variable local to outter function in closure, so we must create it before and declare in global So one can say: "that is because there're no block lambda". (I can be wrong) I think it is possible to introduce block-object in analogy to lambda-object (and function-object) It's difference from function: it has no true self local variables, all global(free) and local variables it steels from outter scope. And all local vars, introduced in block are really introduced in outter scope (i think, during parse state). So its global dicts and local dicts are realy corresponding dicts of outter scope. (Excuse my english) So, may be it would be faster than function call. I don't know. Syntax can be following: lock=Lock() def Some(): local_var1=x local_var2=y local_var3=Z Synhronised(lock,block) local_var3=Here_I_work(local_var1,local_var2,local_var3) return asd(local_var3) def Another(name): local_var1=x local_var2=y FileOpenClose(name,'r',block{f}) local_var3=[[x,y(i)] for i in f] return local_var3 And here is sample of returning value: def Foo(context,proc): context.enter() try: res=proc(context.x,context.y)*2 except Exception,Err: context.throw(Err) finally: context.exit() return res ... context=MyContext() ... def Bar(): result=Foo(context,block{x,y}) continue x+y return result It's idea was token from Ruby. But I think, good idea is good whatever it came from. It can be not Pythonic.

1 0

Pre-PEP: Exception Reorganization for Python 3.0
by Brett Cannon 03 Aug '05

03 Aug '05

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 a certain superclass, and to change bare 'except' clauses to catch a specific superclass. The first and last points I expect some contention, but the middle point I expect people are okay with (Guido liked the idea when Paul Prescod brought it up and the only person who didn't like it, Holger, ended up being okay with it when the superclass had a reasonable name). One thing people might not notice is that I have some minor ideas listed in the tree in parentheses. If people have an opinion on the ideas please speak up. Otherwise the other major points of contention are covered in the Open Issues section or will be brought up in the usual trashing of PEPs that cover contraversial changes. And please realize this is for Python 3.0! None of this is being proposed for any version before then (they could be, but that is another PEP entirely). Hopefully this PEP along with Ping's PEP 344 will cover the major ideas for exceptions for Python 3.0 . -Brett -------------------------------------------------------------- PEP: XXX Title: Exception Reorganization for Python 3.0 Version: $Revision: 1.5 $ Last-Modified: $Date: 2005/06/07 13:17:37 $ Author: Brett Cannon <brett(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Jul-2005 Post-History: XX-XXX-XXX Abstract ======== Python, as of version 2.4, has 38 exceptions (including warnings) in the built-in namespace in a rather shallow hierarchy. This list of classes has grown over the years without a chance to learn from mistakes and cleaning up the hierarchy. This PEP proposes doing a reorganization for Python 3000 when backwards-compatibility is not an issue. It also proposes changing bare ``except`` clauses to catch only exceptions inheriting from a specific superclass. Lastly, this PEP proposes, in Python 3000, that all objects to be passed to a ``raise`` statement must inherit from a specific superclass. Rationale ========= Exceptions are a critical part of Python. While exceptions are traditionally used to signal errors in a program, they have also grown to be used for flow control for things such as iterators. There importance is great. But the organization of the exception hierarchy has not been maintained. Mostly for backwards-compatibility reasons, the hierarchy has stayed very flat and old exceptions who usefulness have not been proven have been left in. Making exceptions more hierarchical would help facilitate exception handling by making catching exceptions much more logical with use of superclasses. This should also help lead to less errors from being too broad in what exceptions are caught in an ``except`` clause. A required superclass for all exceptions is also being proposed [Summary2004-08-01]_. By requiring any object that is used in a ``raise`` statement to inherit from a specific superclass, certain attributes (such as those laid out in PEP 344 [PEP344]_) can be guaranteed to exist. This also will lead to the planned removal of string exceptions. Lastly, bare ``except`` clauses can be made less error-prone [Summary2004-09-01]_. Often people use a bare ``except`` when what they really wanted were non-critical exceptions to be caught while more system-specific ones, such as MemoryError, to pass through and to halt the interpreter. With a hierarchy reorganization, bare ``except`` clauses can be changed to only catch exceptions that subclass a non-critical exception superclass, allowing more critical exceptions to propagate to the top of the execution stack as was most likely intended. Philosophy of Reorganization ============================ There are several goals in this reorganization that defined the philosophy used to guide the work. One goal was to prune out unneeded exceptions. Extraneous exceptions should not be left in since it just serves to clutter the built-in namespace. Unneeded exceptions also dilute the importance of other exceptions by splitting uses between several exceptions when all uses should have been under a single exception. Another goal was to introduce any exceptions that were deemed needed to fill any holes in the hierarchy. Most new exceptions were done to flesh out the inheritance hierarchy to make it easier to catch a category of exceptions with a simpler ``except`` clause. Changing inheritance to make it more reasonable was a goal. As stated above, having proper inheritance allows for more accurate ``except`` statements when catching exceptions based on the inheritance tree. Lastly, any renaming to make an exception's use more obvious from its name was done. Having to look up what an exception is meant to be used for because the name does not proper reflect its usage is annoying and slows down debugging. Having a proper name also makes debugging easier on new programmers. New Hierarchy ============= Raisable (new; rename BaseException?) +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemExit +-- SystemError (subclass SystemExit?) +-- AssertionError +-- SyntaxError +-- IndentationError +-- TabError +-- Exception (replaces StandardError) +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- ControlFlowException (new) +-- StopIteration +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass StopIteration?) +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError (subclass UnicodeEncodeError and UnicodeDecodeError?) +-- LookupError (better name?) +-- IndexError +-- KeyError +-- TypeError +-- AttributeError (subclassing new) +-- OSError (does not inherit from EnvironmentError) +-- WindowsError +-- MacError (new) +-- UnixError (new) +-- IOError (does not inherit from EnvironmentError) +-- EOFError (subclassing new) +-- ImportError +-- NotImplementedError +-- NamespaceException (new) +-- UnboundGlobalError (new name for NameError) +-- UnboundLocalError (no longer subclasses UnboundGlobalError which replaces NameError) +-- WeakReferenceError (rename for ReferenceError) +-- ValueError +-- Warning +-- UserWarning +-- PendingDeprecationWarning +-- DeprecationWarning (subclassing new) +-- SyntaxWarning +-- SemanticsWarning (new name for RuntimeWarning) +-- FutureWarning Differences Compared to Python 2.4 ================================== Changes to exceptions from Python 2.4 can take shape in three forms: removal, renaming, or change in their superclass. There are also new exceptions introduced in the proposed hierarchy. New Exceptions -------------- Raisable '''''''' The base exception **all** exceptions inherit from. The name "Raisable" has been chosen to reflect that it is not meant to be treated as an exception directly, but as the common object that all things to base passed to ``raise`` must inherit from. CriticalException ''''''''''''''''' The superclass for exceptions for which a severe error has occurred that one would not want to catch accidentally. The name is meant to reflect the point that these exceptions are usually raised only when the interpreter should most likely be terminated. MacError '''''''' Introduced for symmertry with WindowsError. UnixError ''''''''' Introduced for symmetry with WindowsError. NamespaceException '''''''''''''''''' To provide a common superclass for exceptions dealing with namespace issues, this exception is introduced. Both UnboundLocalError and UnboundGlobalError (the new name for NameError) inherit from this class. Removed Exceptions ------------------ EnvironmentError '''''''''''''''' Originally meant as an exception for when an event outside of the interpreter needed to raise an exception, its use has been deemed unneeded. While both IOError and OSError inherited this class, the distinction between OS and I/O is significant enough to not warrant having a common subclass that one might base an ``except`` clause on. StandardError ''''''''''''' Originally meant to act as a superclass for exceptions not considered critical, its subclassing was rampant and partially negated its usefulness. The need for StandardError is negated thanks to the CriticalException/Exception dichotomy where Exception takes its place. RuntimeError '''''''''''' Meant to be used when an existing exception does not fit, its usefulness is consider meager in Python 2.4 [exceptionsmodule]_. Also, with the CriticalException/Exception dichotomy, Exception or CriticalException can be raised directly for the same use. Renamed Exceptions ------------------ ReferenceError '''''''''''''' Renamed WeakReferenceError. ReferenceError was added to the built-in exception hierarchy in Python 2.2 [exceptionsmodule]_. Taken directly from the ``weakref`` module, its name comes directly from its original name when it resided in the module. Unfortunately its name does not suggest its connection to weak references and thus deserves a renaming. NameError ''''''''' Renamed UnboundGlobalError. While NameError suggests its use, the name does not properly restrict its scope. With UnboundLocalError already in existence, it seems reasonable to change NameError to UnboundGlobalError to brings its name more in line. RuntimeWarning '''''''''''''' Renamed SemanticsWarning. RuntimeWarning is to represent semantic changes coming in the future. But while saying that affects "runtime" is true, flat-out stating it is a semantic change is much clearer, eliminating any possible association of "runtime" with the virtual machine specifically. Changed Inheritance ------------------- StopIteration and GeneratorExit ''''''''''''''''''''''''''''''' Inherit from ControlFlowException. Collecting all control flow-related exceptions under a common superclass continues with the theme of maintaining a hierarchy. AttributeError '''''''''''''' Inherits TypeError. Since most attribute access errors can be attributed to an object not being the type that one expects, it makes sense for AttributeError to be considered a type error. IOError ''''''' No longer subclasses EnvironmentError. While IOError does fall under the umbrella of EnvironmentError, the need for EnvironmentError has been deemed wanting, and thus has been removed. Thus IOError now subclasses Exception directly. EOFError '''''''' Subclasses IOError. Since an EOF comes from I/O it only makes sense that it be considered an I/O error. UnboundGlobalError and UnboundLocalError '''''''''''''''''''''''''''''''''''''''' Both subclass NamespaceException. Originally UnboundLocalError subclassed NameError (original name of UnboundGlobalError), but with both exceptions specifying a certain namespace, that subclassing has been deemed inappropriate. Instead, a common class between the two of them has been introduced. DeprecationWarning ''''''''''''''''''' Subclasses PendingDeprecationWarning. Since a DeprecationWarning is a PendingDeprecationWarning that is happening sooner, if you care about PendingDeprecationWarnings you are defintely going to care about DeprecationWarnings. Required Base Class for ``raise`` ================================= By requiring all objects passed to a ``raise`` statement, one is guaranteed that all exceptions will have certain attributes. If PEP 342 [PEP344]_ is accepted, the attributes outlined there will be guaranteed to be on all exceptions raised. This should help facilitate debugging by making the querying of information from exceptions much easier. Technically speaking, this can be easily implemented by modifying ``RAISE_VARARGS`` to do an inheritance check and raise TypeError if it does not inherit from Raisable. Bare ``except`` Clauses ======================= Bare ``except`` clauses typically are not meant to catch all exceptions. Often times catching KeyboardInterrupt is not intended. Unfortunately the exception hierarchy in Python 2.4 does not support a simple way to control what exceptions are caught except to be very explicit with a list of exceptions. The reorganization changes this by adding more of a hierarchy. If bare ``except`` statements only catch classes that inherit from Exception, its use will be more in line with what people expect. An implementation can be handled at the bytecode level by modifying the compiler to emit bytecode to do a check for Exception when a bare ``except`` is used. Open Issues =========== Change the Name of Raisable? ---------------------------- It has been argued that Raisable is a bad name to use since it is not an actual word [python-dev1]_. At issue is choosing a name that clearly explains the class' usage. "BaseException" might be acceptable although the name does not quite make it as explicit as Raisable that the class is not meant to be raised directly. Should Bare ``except`` Clauses be Removed? ------------------------------------------ It has been argued that bare ``except`` clauses should be removed entirely [python-dev2]_. The train of thought is that it will force people to specify what they want to catch and not be too broad. One issue with this, though, is whether people will make the proper choices of what to catch or go too broadly. Would a new Python programmer make the right decision and not catch CriticalExceptions or would they go overboard and catch Raisable? It would seem the issue boils down to whether we think people will make proper decisions or make a reasonable solution available for the simplest case assuming they might make a bad one. Change the name of Exception? ----------------------------- Some have suggested names other than "Exception" for the superclass to inherit from for bare ``except`` clauses to match against. The issue with going with a name that is not simplistic is that it raises the chance of people subclassing the wrong exception for what they want. By using the most generic name for the common case it raises the chances that people will use this class for subclassing their own exceptions rather than Raisable or CriticalException. Acknowledgements ================ XXX References ========== .. [PEP342] PEP 342 (Coroutines via Enhanced Generators) (http://www.python.org/peps/pep-0342.html) .. [PEP344] PEP 344 (Exception Chaining and Embedded Tracebacks) (http://www.python.org/peps/pep-0344.html) .. [exceptionsmodules] 'exceptions' module (http://docs.python.org/lib/module-exceptions.html) .. [Summary2004-08-01] python-dev Summary (An exception is an exception, unless it doesn't inherit from Exception) (http://www.python.org/dev/summary/2004-08-01_2004-08-15.html#an-exception-i…) .. [Summary2004-09-01] python-dev Summary (Cleaning the Exception House) (http://www.python.org/dev/summary/2004-09-01_2004-09-15.html#cleaning-the-e…) .. [python-dev1] python-dev email (Exception hierarchy) (http://mail.python.org/pipermail/python-dev/2004-August/047908.html) .. [python-dev2] python-dev email (Dangerous exceptions) (http://mail.python.org/pipermail/python-dev/2004-September/048681.html) Copyright ========= This document has been placed in the public domain.

14 49

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 02 Aug '05

02 Aug '05

Patch / Bug Summary ___________________ Patches : 354 open ( -3) / 2888 closed ( +3) / 3242 total ( +0) Bugs : 909 open (+11) / 5152 closed ( +8) / 6061 total (+19) RFE : 191 open ( +0) / 178 closed ( +0) / 369 total ( +0) Patches Closed ______________ PEP 342 Generator enhancements (2005-06-18) http://python.org/sf/1223381 closed by pje Provide tuple of "special" exceptions (2004-10-01) http://python.org/sf/1038256 closed by ncoghlan Patch for (Doc) #1243553 (2005-07-24) http://python.org/sf/1243910 closed by montanaro New / Reopened Bugs ___________________ "new" not marked as deprecated in the docs (2005-07-30) http://python.org/sf/1247765 opened by Jürgen Hermann error in popen2() reference (2005-07-30) CLOSED http://python.org/sf/1248036 opened by Lorenzo Luengo pdb 'next' does not skip list comprehension (2005-07-31) http://python.org/sf/1248119 opened by Joseph Heled set of pdb breakpoint fails (2005-07-31) http://python.org/sf/1248127 opened by Joseph Heled shelve .sync operation not documented (2005-07-31) http://python.org/sf/1248199 opened by paul rubin dir should accept dirproxies for __dict__ (2005-07-31) http://python.org/sf/1248658 opened by Ronald Oussoren 2.3.5 SRPM fails to build without tkinter installed (2005-07-31) http://python.org/sf/1248997 opened by Laurie Harper rfc822 module, bug in parsedate_tz (2005-08-01) http://python.org/sf/1249573 opened by nemesis isinstance() fails depending on how modules imported (2005-08-01) http://python.org/sf/1249615 opened by Hugh Gibson Encodings and aliases do not match runtime (2005-08-01) http://python.org/sf/1249749 opened by liturgist container methods raise KeyError not IndexError (2005-08-01) http://python.org/sf/1249837 opened by Wilfredo Sanchez numarray in debian python 2.4.1 (2005-08-01) CLOSED http://python.org/sf/1249867 opened by LovePanda numarray in debian python 2.4.1 (2005-08-01) CLOSED http://python.org/sf/1249873 opened by LovePanda numarray in debian python 2.4.1 (2005-08-01) http://python.org/sf/1249903 opened by LovePanda IDLE does not start. 2.4.1 (2005-08-01) CLOSED http://python.org/sf/1249965 opened by codepyro gethostbyname(gethostname()) fails on misconfigured system (2005-08-02) http://python.org/sf/1250170 opened by Tadeusz Andrzej Kadlubowski incorrect description of range function (2005-08-02) http://python.org/sf/1250306 opened by John Gleeson The -m option to python does not search zip files (2005-08-02) http://python.org/sf/1250389 opened by Paul Moore Tix: PanedWindow.panes nonfunctional (2005-08-02) http://python.org/sf/1250469 opened by Majromax Bugs Closed ___________ Segfault in Python interpreter 2.3.5 (2005-07-26) http://python.org/sf/1244864 closed by birkenfeld logging module doc needs to note that it changed in 2.4 (2005-07-25) http://python.org/sf/1244683 closed by vsajip manual.cls contains an invalid pdf-inquiry (2005-07-14) http://python.org/sf/1238210 closed by fdrake error in popen2() reference (2005-07-30) http://python.org/sf/1248036 closed by birkenfeld numarray in debian python 2.4.1 (2005-08-01) http://python.org/sf/1249867 closed by birkenfeld numarray in debian python 2.4.1 (2005-08-01) http://python.org/sf/1249873 closed by birkenfeld IDLE does not start. 2.4.1 (2005-08-01) http://python.org/sf/1249965 closed by codepyro Incorrect documentation of re.UNICODE (2005-07-22) http://python.org/sf/1243192 closed by birkenfeld

1 0

Syscall Proxying in Python
by Gabriel Becedillas 02 Aug '05

02 Aug '05

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

2 3

__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)
by falcon 02 Aug '05

02 Aug '05

Hello python-list, As I Understood, semantic may be next: def qwerty(a,a.i,b,b.i,f.j): pass Would work like: def qwerty(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5): (a,a.i,b,b.i,f.j)=(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5) del anonymous1 del anonymous2 del anonymous3 del anonymous4 del anonymous5 If so then I like it, because it more explicit than anything other and it is working right now. I just tryed: >>> class Stub: ... pass >>> def qwer(a1,a2,a3,a4,a5): ... (a,a.i,b,b.i,f['i'])=(a1,a2,a3,a4,a5) ... del a1 ... del a2 ... del a3 ... del a4 ... del a5 ... print (a,a.i,b,b.i,f['i']) >>> f={} >>> qwer(Stub(),1,Stub(),2,3) (<__main__.Stub instance at 0x00C49530>, 1, <__main__.Stub instance at 0x00C498C8>, 2, 3) So there are not too much for implement. Another question - named arguments. How I can assign to them? May be so: f={} def qwerty(a,a.i,f['i']): print (a,a.i,f['i']) qwerty(f['i']=3,a=Stub(),a.i=4) - ? and for __init__: class MyClass: def __init__(self,self.i,self.j,self.k): pass MyObject = MyClass(self.i=1,self.j=2,self.k=3) ? or may be there can be an aliase syntax? class MyClass: def __init__(self, self.i by i,self.j by j, self.k by k): pass MyObject = MyClass(i=1,j=2,k=3) -- Sokolov Yura falcon(a)intercable.ru

2 1

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
by Delaney, Timothy (Tim) 01 Aug '05

01 Aug '05

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

3 2

Extension of struct to handle non byte aligned values?
by George V. Neville-Neil 01 Aug '05

01 Aug '05

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

2 1