Help understanding the decisions *behind* python?

[Terry Reedy]

Emmanuel Surleau wrote:
> 
>> Beyond the mutable/hashable distinction, there is an important 
>> philosophical distinction articulated by Guido.  He deems tuples to
>> be useful for struct like groupings of non-homogenous fields and
>> lists to be useful for sequences of homogenous data suitable for
>> looping.

I think the use of the with 'homegeneous' in this context is wrong
because 1) it is ambiguous or even sometimes not the case, and 2) it
misleads. Everything is an object, so all collections are in that sense
homogeneous. If the meaning is restricted to type(ob), than a list
'mixing' ints and floats would be non-homogeneous and not 'legitimate',
but Guido does not really mean that.

The word tuple comes from relational databases as a generalization of
single, double, triple, quadruple, quintuple, sextuple, sestuple,
octuple, etc. A tuple is a data record with a fixed number of fields
with individual meaning. There is nothing about homogeneity of data type
in that definition. A triple of floats is legitimately a tuple when each
is a coordinate (the individual meanings). In other contexts, the same
triple might properly be a list (such as of heights of people
arbitrarily ordered).

>> While nothing in the list/tuple code requires you to make that 
>> distinction,

which needs to be properly articulated...

>> it is important because that philosophy pervades the language.  If
>> you follow Guido's direction, you'll find that the various parts of
>> the language fit together better.  Do otherwise and you'll be going
>>  against the grain.

Understanding the idea certainly helps understanding the design.
For instance, it explains why no tuple comprehensions.

> I might be wrong, but I get the impression that many people don't
> indeed "get it" and use tuples as static arrays and lists when the
> array needs to be dynamically resized. This is certainly how I use
> them as well.

You also *need* lists if you want to dynamically re-arrange or replace. 
If you *must not* re-arrange or edit, then a tuple will prevent that.

I would also refer back to the idea of tuple as database record.
But a list is needed to edit without copying, so lists can be used for 
writable database records.

I believe tuple(iterable) for indefinite-length iterables is somewhat 
equivalent to tuple(list(iterable)), so there is usually no point to 
constructing a  tuple that way from such an input.

For collections defined by constants, there is a real advantage to using
tuples, since tuple constants are compiled when the bytecode is 
compiled, rather than being dynamically constructed. Inside an inner 
loop, this might make enough time difference that "Practicality beats 
purity" would apply.

> This would tend to show that Guido's notion here was not particularly
>  intuitive.

The problem is that it *is* intuitive, on his part, and usually not well
explained rationally.

Terry Jan Reedy