tuples, index method, Python's design

[Donn Cave]

In article <slrnf1pq6s.klv.apardon at rcpc42.vub.ac.be>,
 Antoon Pardon <apardon at forel.vub.ac.be> wrote:

> On 2007-04-11, Marc 'BlackJack' Rintsch <bj_666 at gmx.net> wrote:
> > In <slrnf1pnng.klv.apardon at rcpc42.vub.ac.be>, Antoon Pardon wrote:
> >
> >> On 2007-04-11, Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> 
> >> wrote:
> >>> Lists are designed for sequences of homogeneous items, e.g.:
> >>>
> >>> L = [1, 2, 4, 8, 16, 32]
> >>> while tuples are designed to be more like structs or records, with
> >>> heterogeneous items, e.g.:
> >>>
> >>> T = ("Fred", 32, 12.789, {}, None, '\t')
> >> 
> >> I think you are confused. Last time I heard this homogeneous items stuf,
> >> it had nothing to do with the types being the same. They were homogeneous
> >> because they somehow belonged together and heterogeneous because they
> >> just happened to live together. Similarity of type played no part in
> >> calling the data homogeneous or heterogeneous.
> >
> > Then you are confused.  The typical use case for tuples are database
> > records.  The columns in the table can have completely different types but
> > the values in a row, represented as a Python tuple, of course belong
> > together.
> 
> Don't blame me. I don't agree with the view. But that was sort of the
> explanation that was given here last time I remember this topic came 
> up in defending why tuples and lists differ in a number of ways that
> are less obvious.
>
> They wrote about lists containing homogeneous items and tuples
> containing hetergenous items but stressed rather strongly that
> this shouldn't be understood in terms of type similarities.

Well, yes - consider for example the "tm" tuple returned
from time.localtime() - it's all integers, but heterogeneous
as could be - tm[0] is Year, tm[1] is Month, etc., and it
turns out that not one of them is alike.  The point is exactly
that we can't discover these differences from the items itself -
so it isn't about Python types - but rather from the position
of the item in the struct/tuple.  (For the person who is about
to write to me that localtime() doesn't exactly return a tuple:  QED)

   Donn Cave, donn at u.washington.edu