This is just a simple copy and paste from the list implementation - not exactly the most elegant solution, but perhaps a demonstration that technical limitations aren't the reason why the tuple doesn't have an index method. I suppose a common sequence function library would be best if such a feature were eventually deemed compelling.

Adding an .index method to tuples suggests that a tuple is more or less an immutable list.  This is not the case.  Typically tuples are used to hold disparate pieces of information of different semantics and types, where as a list typically contains a list of a single type with identical meaning.  For examples we merely need to look at the outputs of str.partition and str.split .

Suggested close.

FWIW, I am no longer satisfied with the pat answer that "tuples are not immutable lists" or the "lists for for homogenous data, tuples are for hetrogenous data".

Whether tuples should grow index() and count() methods should depend solely on whether real use cases arise often enough to warrant the new methods being added.

Another consideration is that this feature request and discussion comes up so often that it may be worthwhile just to give-in to conserve our limited resources of time and brain-power.

See here for a recent extension of the discussion:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/7e9327a896c242e7/

For what it's worth, bypassing the dogma, methods like index and count on tuples are not exactly compelling in many situations (as I've pointed out before), but such issues should hardly derail the core development effort. If people consider such methods useful and if it diminishes perceived inelegance without method proliferation, just add them: people will be less frustrated and feel listened to; the language will become more regular.

The only downside is any additional memory consumption. Objections related to what such methods mean, or what a tuple itself should be taken to mean, risk venturing into dogma and a consequent time-consuming discussion which takes 100 times the effort of just getting stuff done. Just look at the referenced thread (and the others of recent times) for example material.

I wouldn't be averse to adding utility functions to some module where it would make sense.  Generally, I would say collections (it has a deque and default dictionary already), though there is already a proposed constructor called 'count' that returns the counts of all items in a sequence as a default dictionary (requiring that the items all be hashable).

The reason I'm not against utility functions is because then they would be usable for 3rd party non-list, non-tuple sequences, or even usable in cases like 'a = array.array(...); i = index(a, value)'.

Adding a utility function for this is silly.  Don't ignore the obvious, simple solution.  If a type *needs* a method, add it.  If not, don't. 

Also, the collecitons module should be about collections, not a dumping ground for random utility functions.

This patch is not acceptable in its current form, because it does not include test suite and documentation changes.

Furthermore, as the objective seems to be consistency across collections, I would say that the patch should either add both count and index, or none at all. Even with that added, the collections would still not behave consistently: strings have many more linear-search methods (.rindex, .find, .rfind).

Py2.6 and Py3.0 now how have tuple.index() and tuple.count().