tuple.index()

[Nick Maclaren]

In article <mailman.1607.1166112864.32031.python-list at python.org>,
Carsten Haese <carsten at uniqsys.com> writes:
|> > |> 
|> > |> so where would you put such an "index" implementation so it would work on
|> > |> ANY data structure that can be subscripted by an integer value ?
|> > 
|> > In the same place you put the subscription method, clearly.
|> 
|> Clearly not, because that would force *every* object that implements
|> __getitem__ to also implement index.

Well, yes, but why is that impossible?  You may feel that it is
undesirable, but that is not the same at all.  And there is no problem
with providing a generic default version of index that just does a
linear search, so only objects that wanted to optimise index would
need to provide anything.

|> And to verify the truth of your assertion that index makes sense for
|> "ANY data structure that can be subscripted by an integer value",
|> consider the following theoretical but conceivable examples:
|> 
|> 1) A mailbox object that returns the i-th message on subscripting.
|> 2) A scroll cursor in a database that returns the i-th row of the result
|> set.
|> 3) A prime number generator that calculates the i-th prime number.
|> 
|> Does .index() make sense for them? How would it be implemented?

You are correct that it does also need some sort of a concept of
equivalence, but a language like Python always has one - the 'is'
operator, if nothing else.

index makes sense for all of the above examples, and the implementation
couls be based on 'is' for (1) and (2), and on value for (3).  And, as
mentioned above, it could be implemented as a linear search, if nothing
else works.

Mathematically, the counterexamples are only lists of entities where
there is no definable concept of equivalence between entities, and
Python has no such entities as far as I know.

Guido's response is fine - we didn't because we didn't think that it
was worth doing.  One can dissent, but it makes perfect sense.


Regards,
Nick Maclaren.