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