[Python-Dev] an idea for improving struct.unpack api

[Raymond Hettinger]

[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