tuples, index method, Python's design

[Chris Mellon]

On 4/12/07, Alan Isaac <aisaac at american.edu> wrote:
> I am still puzzled by this discussion.
>
> As I said:
> I doubt that *anyone* who programs in Python
> has not encountered the situation where they change
> a tuple to a list *solely* for the purpose of getting
> access to the index method. This suggests a missing
> method, does it not?  Who has not done this?
> Name yourself!
>

Sure. I have never done this. In fact, I have only ever written code
that converted a tuple to a list once, and it was because I wanted
pop(), not index() - I had a varargs argument that iterated over it's
argument list and need to know how many arguments it had consumed, and
how many were left, in order to correctly process the current
argument. Using a list was (very) slightly more convenient for this
than counting. Note that because I needed to preserve the original
argument to compare against, *args being a list wouldn't have changed
the way I wrote it even if it was technically feasible to implement it
as one.

> There is simply no conflict between the index method and immutability,
> but at the moment one is forced to choose.  Why?  Nobody has
> offered a real explanation of this.
>

There have been many. The answer is, in the cases where you need
immutability, you don't need index, because an immutable structure is
either unordered, so index doesn't matter, or ordered, and the order
is then part of the structure.

> I offered a simple use case.  Consider a game,
> where the *fixed* set p of players have a *fixed* order.
> A tuple is natural.  Now for a player you want to
> construct the opponents.  If I had the index i it wd
> be p[:i]+p[i+1:], but how to get the index?
>

I would never use a tuple for this case, I would use a list. And even
using the list, I wouldn't use index() to find the current player. I'd
get the other players via a list comp (as shown previously in the
thread) or I'd be iterating through the player list and I'd already
have the other players. I find the solution you posted to be poor and
if tuple not having index() has *no other effect* than to discourage
the writing of code in this style I'd consider the decision justified.
Depending on the exact game play, almost any data structure *except* a
tuple would be a better solution.

> Other use cases have also been offered on this thread.

I, for one, have found none of them compelling and have said why I
don't find them compelling. There is one which I think is reasonable.
Manually searching the tuple or conversion to a list addresses that
use case, which I don't expect to be common.

> What is the basic response?  "Do not worry about the
> loss of immutability, just use a list."  What kind of a
> response is that??  This sounds to me like "I do not
> really see the point of immutability", which is no
> response at all.
>

How about "explain why you find immutability necessary in this
context. If you can't explain it, then don't worry about".

> Cheers,
> Alan Isaac