On Fri, 7 Jan 2005 19:40:18 -0800 (PST), Ilya Sandler [EMAIL PROTECTED] wrote:
Eg. I just looked at xdrlib.py code and it seems that almost every
invocation of struct._unpack would shrink from 3 lines to 1 line of code
(i = self.__pos
self.__pos = j = i+4
data =
First, let me say two things:
(a) A higher-level API can and should be constructed which acts like a
(binary) stream but has additional methods for reading and writing
values using struct format codes (or, preferably, somewhat
higher-level type names, as suggested). Instances of this API should
Bob Ippolito [EMAIL PROTECTED] writes:
On Jan 6, 2005, at 8:17, Michael Hudson wrote:
Ilya Sandler [EMAIL PROTECTED] writes:
A problem:
The current struct.unpack api works well for unpacking C-structures
where
everything is usually unpacked at once, but it
becomes inconvenient when
I will try to respond to all comments at once.
But first a clarification:
-I am not trying to design a high-level API on top of existing
struct.unpack and
-I am not trying to design a replacement for struct.unpack
(If I were to replace struct.unpack(), then I would probably go along
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
On Jan 6, 2005, at 8:17, Michael Hudson wrote:
Ilya Sandler [EMAIL PROTECTED] writes:
A problem:
The current struct.unpack api works well for unpacking C-structures
where
everything is usually unpacked at once, but it
becomes inconvenient when unpacking binary files where things
often have to be
[Ilya Sandler]
A problem:
The current struct.unpack api works well for unpacking C-structures
where
everything is usually unpacked at once, but it
becomes inconvenient when unpacking binary files where things
often have to be unpacked field by field. Then one has to keep track
of offsets,
