Tuples, what are they: read-only lists or heterogeneous data arrays?

[Alex Martelli]

Thomas Wouters wrote:

> On Wed, Mar 12, 2003 at 03:02:29PM -0800, Nicola Larosa wrote:
> 
> [ Guido rejects the 'add-list-methods-to-tuples' patch ]
> 
>> Sorry, but this makes no sense. I entirely support the notion that a
>> tuple should be *exactly* like a list, apart from the fact that it is
>> immutable, so every read-only list method should be available for
>> tuples, too.
> 
> You must have missed the posting that started this thread. Tuples *are
> not* lists, and should not be used as 'read-only lists' for the sake of
> having a read-only list or for the sake of performance. Tuples are more of

So what would you propose to do, when somebody needs to use a list as
a key into a dictionary -- a list that's not going to be subject to any
more changes, but will often need to be subject to non-mutating method
calls such as .count ?  Peppering the code with type conversion calls
tuple(this) and list(that) is then a serious violation of the idea that
"practicality beats purity".

If tuples are NOT to be used as "frozen lists" for such purposes as
indexing into a dictionary, putting into a set, and so on, then we need
a separate way to "freeze a list" (or "get a frozen equivalent of a
list", that would be fine too) -- perhaps along the same lines by which
sets can be "frozen" into immutable-sets in the sets.py module.  I think
it might be a very nice addition (particularly if done via a protocol
that also applied to dicts and that users could implement for their own
classes if they wish to).

But as long as tuples are the one and only way to "use a list as a
dict key" &c, the theoretical arguments about tuples not being just
frozen lists are countered by too much practical baggage, IMHO.


Alex