[Python-Dev] an idea for improving struct.unpack api (original) (raw)

Raymond Hettinger python at rcn.com
Sat Jan 8 06:20:43 CET 2005

[Ilya Sandler]

I view struct module as a low-level (un)packing library on top on which a more complex stuff can be built and I am simply suggesting a way to improve this low level functionality... > > We could have an optional offset argument for > > > > unpack(format, buffer, offset=None) > > > > the offset argument is an object which contains a single integer field > > which gets incremented inside unpack() to point to the next byte.

-1 on any modification of the existing unpack() function. It is already at its outer limits of complexity. Attaching a stateful tracking object (needing its own constructor and api) is not an improvement IMO. Also, I find the proposed "offset" object to be conceptually difficult to follow for anything other than the simplest case -- for anything else, it will make designing, reviewing, and debugging more difficult than it is now.

In contrast, code built using the StructReader proposal leads to more flexible, readable code. Experience with the csv module points to reader objects being a better solution.

[Nick Coghlan]

How about making offset a standard integer, and change the signature to return a tuple when it is used:

item = unpack(format, rec) # Full unpacking offset = 0 item, offset = unpack(format, rec, offset) # Partial unpacking The second item in the returned tuple being the offset of the first byte after the end of the unpacked item

Using standard integers helps improve the proposal by making the operation less obscure. But having than having the signature change is bad; create a separate function instead:

item, offset = unpack_here(format, rec, offset)

One other wrinkle is that "item" is itself a tuple and the whole thing looks odd if unpacked:

((var0, var1, var2, var3), offset) = unpack_here(fmtstr, rec,

offset)

Raymond

More information about the Python-Dev mailing list