[Tutor] Distinction between tuples and lists

[jadrifter]

On Thu, 2009-01-01 at 15:07 +0100, Christopher Mutel wrote:
> Hello all-
> 
> I stumbled across some discussion of why the fundamental difference
> between lists and tuples is not mutability, but hetero- versus
> homogeneous data, e.g.
> 
> http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/
> 
> http://pyre.third-bit.com/blog/archives/000450.html
> 
> However, after reading the cited discussions, my python books, etc., I
> have to admit I don't really understand this idea. What does it mean
> that "lists are intended for homogeneous sequences"? What is different
> about lists that would make them more suited for homogeneous sequences
> than heterogeneous sequences (or vice-versa for tuples)? In the end,
> from what I understand, the idea of homo/heterogeneity seems
> orthogonal to mutability, which is the main distinction emphasized by
> e.g. Learning Python.
> 
> I would greatly appreciate any help provided,
> 
> -Chris Mutel
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor

I read it and don't get their emphasis or perhaps level of concern.  As
explanatory pieces these two blogs aren't very helpful.  They provide a
few assertions with no apparent (to me) attempt to support or explain
them.  

Both data types are indexed and both can contain homogeneous (same as)
or heterogeneous (different than) data.  I get that lists are analogous
to a C linked lists as tuples are to C structs.  I get that the
flexibility of one and the stability of the other makes them useful in
different situations.  Being able to use struct notation (employee.age
instead of employee[4]) would be nice but also not that difficult to
implement as a class either.

On re-re-re-reading it (I hate it when I don't get the point) I think
they're arguing for a more structured "You must use this properly"
approach to be built into the language.  And that makes some sense.  Who
would want a database call (say to an employee database table) that
returned  a record as a list?  On the other hand who would want a record
set (group of records) returned as a tuple?  There's no reason to assume
the third record will always be that of John Smith but the 3rd field of
John Smiths's record better be his phone number and not his social
security number or else wackiness will ensue.

Still, aint it great to work with a language that lets us bounce back
and forth between structures as we please?

John Purser