RetroSearch Browse

Sat Jan 8 08:15:23 CET 2005 · https://mail.python.org/pipermail/python-dev/2005-January/050797.html

Ilya Sandler wrote:
>>How about making offset a standard integer, and change the signature to
>>return  tuple when it is used:
>> item, offset = unpack(format, rec, offset) # Partial unpacking
> 
> 
> Well, it would work well when unpack results are assigned to individual
> vars:
> 
>    x,y,offset=unpack( "ii", rec, offset)
> 
> but it gets more complicated if you have something like:
>    coords=unpack("10i", rec)
> 
> How would you pass/return offsets here? As an extra element in coords?
>    coords=unpack("10i", rec, offset)
>    offset=coords.pop()
> 
> But that would be counterintuitive and somewhat inconvinient..

I was thinking more along the lines of returning a 2-tuple with the 'normal' 
result of unpack as the first element:

   coords, offset = unpack("ii", rec, offset)
   x, y = coords

Raymond's suggestion of a separate function like 'unpack_here' is probably a 
good one, as magically changing function signatures are evil. Something like:

def unpack_here(format, record, offset = 0):
   end = offset + calcsize(format)
   return (unpack(format, record[offset:end]), end)

Presumably, a C version could avoid the slicing and hence be significantly more 
efficient.

Yes, the return type is a little clumsy, but it should still make it easier to 
write more efficient higher-level API's that unpack the structure a piece at a time.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-January/050797.html below:

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