> 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
21 matches
Mail list logo
