tuple.index()

[Nick Maclaren]

In article <em0i1g$mpe$1 at online.de>, Christoph Zwerschke <cito at online.de> writes:
|> 
|> I just found that there is indeed some mentioning in the FAQ here:
|> http://www.python.org/doc/faq/general/#why-are-there-separate-tuple-and-list-data-types
|> But it is a bit vague, too, and does not mention whether there is any 
|> difference in efficiency which would be interesting to know as well.

It is a trifle bizarre, much like most of the reasons that have been
given in this thread.  I know only some of how Python is implemented,
but have a lot of relevant experience, and here is some commentry on
the FAQ.

The mutability one is the key.  See 1.4.19 for a reason.  In a less
functional language, a tuple would be a value and a list a variable.
You CAN implement dictionaries using mutable objects as keys, but
the result is to add a large amount of inefficiency, complication,
and confusion, for next to no useful function.

The homogeneity argument baffles me.  While it is relevant to some
languages, I know of nothing within either Python's design or its
implementation that makes it relevant to Python.  There may be some
abstruse aspect that I have missed, and I should be very interested
if anyone can explain it.

Both of these are orthogonal to whether tuples should support count
and index methods.  Guido has given a clear answer "We didn't think
it was worth doing."

In terms of efficiency, it is clearly possible to implement tuples
more efficiently, as there is a lot of mechanism that lists need that
they don't.  This accounts for the measurements people have made but,
as Guido says, it is EXTREMELY unlikely that any real application
will notice the difference.  The extra cost is almost entirely in the
setup, as the current implementation of list indexing is near-optimal.

It would also be possible to improve lists to make insertion an
O(log N) operation, not an O(N) one as at present, at the expense of
increasing the cost of indexing.  Not necessarily as much as from the
present O(1) to O(log N), but still significantly.  Python has chosen
not to do that.


Regards,
Nick Maclaren.