On Aug 28, 1:59 am, Tim Roberts <[EMAIL PROTECTED]> wrote: > castironpi <[EMAIL PROTECTED]> wrote: > > >I'd like to seriously nominate this idea and get a considered opinion > >on it. > > >struct.Struct lets you encode Python objects into structured memory. > >It accepts a format string, and optionally a buffer and offset to/from > >which to read/write the structure. What do you think of random access > >to the results? To avoid Marc's concern about meaningless anonymous > >record entries, model the constructor after 'namedtuple' type. > > >(unproduced) > >>>> packer= struct.Struct( 'IIIf255p', 'i1 i2 i3 afloat name' ) > >>>> packer.pack_into( buf, off, 10, 20, 30, 0.5, 'abc' ) > >>>> packer.unpack_from( buf, off, 'i3' ) > >30 > >>>> packer.unpack_from( buf, off ) > >( 10, 20, 30, 0.5, 'abc' ) > >>>> packer.pack_into( buf, off, 'i1', 12 ) > > What data type would you expect "buf" to be? Your design requires it to be > both an input and an output parameter. Today's "struct" converts into and > out of a string, and strings are immutable. So, to continue with that > standard, you would have to pass a string into "pack_into" and have the > modified result returned as an output: > > buf = packer.pack_into( None, 0, 10, 20, 30, 0.5, 'abc' ) > buf = packer.pack_into( buf, 0, 'i1', 12 ) > > In the end, I'm not sure you are really saving anything. > > >Even in sequential access speed benefits, by avoiding the construction > >of n-1 objects. > > This is a fairly major change, because it requires a "struct.Struct" object > to maintain state, something that the "struct" module currently does not > do. > > In my personal opinion, this is a rather large and confusing change, for > very little benefit. > -- > Tim Roberts, [EMAIL PROTECTED] > Providenza & Boekelheide, Inc.
CMIIW correct me if I'm wrong, I don't think that pack_into returns a value the way that pack does. The syntax is ambiguous in the case of two-element structs: are you packing a new struct or assigning a field? Maybe the field name needs a keyword. A field name can be a third argument in unpack_from regardless, however. Or use the field name as keyword: strt.pack_into( buf, off, i1= 32 ). I just tried an experiment with an Mmap and PyObject_AsWriteBuffer. Mmaps could work but you would not be able to use arbitrary strings. You would have to specially allocate a ctypes buffer with a size to match the packed size of the structure. -- http://mail.python.org/mailman/listinfo/python-list
