The followup: I've implemented a new StructView-object for 3.3a-trunk.
The object takes and existing Struct-object and provides on-access
unpacking. The breaking point where this object is faster than calling
Struct.unpack seems to be somewhere around 12 fields in the
format-string. Format strings
> So I really can't see what harm it could do, except for
> maybe a tiny performance reduction in the case where you
> extract all the fields, or refer to extracted fields
> repeatedly.
Referring to the view-object multiple times should not be a problem
since the object can create and hold referen
Raymond Hettinger wrote:
How would you describe the creation of a lazy result
that keeps a reference to the underlying buffer?
I'd call it a view. There is plenty of precedence for this
kind of object in Python -- I gave a few examples before.
The distinguishing feature of ropes, as I underst
Le dimanche 12 juin 2011 à 10:27 -0700, Raymond Hettinger a écrit :
> I do suggest that you publish your code as a third-party module
> to make the optional available and to validate whether there
> is any real interest in this.
See the Hachoir project: it is a lazy parser supporting sub-structure
On Mon, Jun 13, 2011 at 6:31 AM, Terry Reedy wrote:
> With just 1 or 2 filter fields, and very many other fields, I would just
> unpack everything, including the filter field. I expect the extra time to do
> that would be comparalbe to the extra time to combine. It certainly would
> make your code
On Jun 12, 2011, at 3:18 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> The problem you're trying to solve isn't unique to structs.
>> That's why we get periodic requests for ropes-like behaviors
>
> I don't think he's asking for rope-like behaviour here.
How would you describe the crea
Raymond Hettinger wrote:
The problem you're trying to solve isn't unique to structs.
That's why we get periodic requests for ropes-like behaviors
I don't think he's asking for rope-like behaviour here.
Rather, he's asking for iterator-like or view-like
behaviour -- for the same reasons we have
On 6/12/2011 11:29 AM, Lukas Lueg wrote:
This sort of speculative idea might fit the python-ideas list better.
[Summary: we often need to extract a field or two from a binary record
in order to decide whether to toss it or unpack it all and process.]
One solution to this is using two format-
> This is what people normally do (unpack just the values they need,
> when they need them).
Due to the fact that there hundreds of format-strings which
dynamically compiled from a more verbose language at runtime, we will
have significant complexity in the code in order to generate format
strings
On Jun 12, 2011, at 8:29 AM, Lukas Lueg wrote:
> Hi.
>
> We extensively use the struct module to crunch large amounts of binary
> data. There are basically two operations for us that only seem to the
> naked eye as one: Filtering (see if certain fields have certain
> values, throw everything awa
Hi.
We extensively use the struct module to crunch large amounts of binary
data. There are basically two operations for us that only seem to the
naked eye as one: Filtering (see if certain fields have certain
values, throw everything away if not) and inspection (care about all
the fields' values).
11 matches
Mail list logo
