In article <[EMAIL PROTECTED]>, Carsten Haese <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
