Help understanding the decisions *behind* python?
tjreedy at udel.edu
Fri Jul 31 21:55:11 CEST 2009
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
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
>> While nothing in the list/tuple code requires you to make that
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
The problem is that it *is* intuitive, on his part, and usually not well
Terry Jan Reedy
More information about the Python-list