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. -- http://mail.python.org/mailman/listinfo/python-list