In article <[EMAIL PROTECTED]>,
 "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:

> Alex Martelli wrote:
> 
> > Steve Holden <[EMAIL PROTECTED]> wrote:
> >    ...
> > > Presumably because it's necessary to extract the individual values
> > > (though os.stat results recently became addressable by attribute name as
> > > well as by index, and this is an indication of the originally intended
> > > purpose of tuples).
> >
> > Yep -- "time tuples" have also become pseudo-tuples (each element can be
> > accessed by name as well as by index) a while ago, and I believe there's
> > one more example besides stats and times (but I can't recall which one).
> >
> > Perhaps, if the tuple type _in general_ allowed naming the items in a
> > smooth way, that might help users see a tuple as "a kind of
> > ``struct''... which also happens to be immutable".  There are a few such
> > "supertuples" (with item-naming) in the cookbook, but I wonder if it
> > might not be worth having such functionality in the standard library
> > (for this clarification as well as, sometimes, helping the readability
> > of some user code).
> 
> iirc, providing a python-level API to the SequenceStruct stuff
> has been proposed before, and rejected.
> 
> (fwiw, I'm not sure the time and stat tuples would have been
> tuples if the standard library had been designed today; the C-
> level stat struct doesn't have a fixed number of members, and
> the C-level time API would have been better off as a light-
> weight "time" type (similar to sockets, stdio-based files, and
> other C-wrapper types))

Right.  After devoting a lengthy post to the defense of
tuples as a structured type, I have to admit that they're
not a very good one - it's hard to think of many structured
values that are ideally expressed by a fixed length vector
with elements accessed by integer index.

Another theme that occasionally comes up in advice from the
learned has been "use a class".  Of course for values that
are related to some external structure, you'd want to provide
something to make tuple(a) work, serialization etc., and you'd
probably end up with something a lot like StructSequence.
Meanwhile losing a significant overhead.

I wrote a quickie Python API to SequenceStruct and used it to
make an (x, y) coord type, to compare with a Coord.x,y class.
A list of a million coords used 1/5 space, and took 1/10 the
time to create.  Hm.

   Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to