> Instead, I would suggest that even a very limited initial
> implementation of StructReader() like object suggested by Raymond
would
> be more useful...
I have a draft patch also.
Let's work out improvements off-list (perhaps on ASPN).
Feel free to email me directly.
Raymond
__
> (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
> be constructable from a
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
be
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
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, o
> 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
[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=No
Ilya Sandler wrote:
item=unpack( "", rec, offset)
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
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
Thomas Heller <[EMAIL PROTECTED]> writes:
>> Bob Ippolito <[EMAIL PROTECTED]> writes:
>
>>> This is my ctypes-like attempt at a high-level interface for struct.
>>> It works well for me in macholib:
>>> http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
>
> Michael Hudson <[EMAIL PROT
On Jan 7, 2005, at 9:33 AM, Thomas Heller wrote:
Bob Ippolito <[EMAIL PROTECTED]> writes:
This is my ctypes-like attempt at a high-level interface for struct.
It works well for me in macholib:
http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
Michael Hudson <[EMAIL PROTECTED]> writes
> Bob Ippolito <[EMAIL PROTECTED]> writes:
>> This is my ctypes-like attempt at a high-level interface for struct.
>> It works well for me in macholib:
>> http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py
Michael Hudson <[EMAIL PROTECTED]> writes:
>
> Unsurprisingly, that's fairly s
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
>>> bec
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 b
On Thu, 2005-01-06 at 13: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
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 unpacked field by field. Then one
Paul Moore <[EMAIL PROTECTED]> writes:
> On Thu, 6 Jan 2005 21:28:26 +1100, Anthony Baxter
> <[EMAIL PROTECTED]> wrote:
>> My take on this:
>>
>> struct.pack/struct.unpack is already one of my least-favourite parts
>> of the stdlib. Of the modules I use regularly, I pretty much only ever
On Thu, 6 Jan 2005 21:28:26 +1100, Anthony Baxter
<[EMAIL PROTECTED]> wrote:
> My take on this:
>
> struct.pack/struct.unpack is already one of my least-favourite parts
> of the stdlib. Of the modules I use regularly, I pretty much only ever
> have to go back and re-read the struct (an
My take on this:
struct.pack/struct.unpack is already one of my least-favourite parts
of the stdlib. Of the modules I use regularly, I pretty much only ever
have to go back and re-read the struct (and re) documentation because
they just won't fit in my brain. Adding additional com
On 2005 Jan 06, at 06:27, Ilya Sandler wrote:
...
We could have an optional offset argument for
unpack(format, buffer, offset=None)
I do agree on one concept here: when a function wants a string argument
S, and the value for that string argument S is likely to come from some
other bigger strin
[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 of
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, slice the strings,cal
22 matches
Mail list logo
