classification
Title: Adding an index method to tuples
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.0, Python 2.6
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: josiahcarlson, loewis, pboddie, rhettinger
Priority: normal Keywords: patch

Created on 2007-04-08 14:35 by pboddie, last changed 2008-02-07 06:25 by rhettinger. This issue is now closed.

Files
File name Uploaded Description Edit
tuple_index_26.diff pboddie, 2007-04-08 14:35 Patch adding tuple.index to the trunk
Messages (8)
msg52400 - (view) Author: Paul Boddie (pboddie) Date: 2007-04-08 14:35
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.
msg52401 - (view) Author: Josiah Carlson (josiahcarlson) * (Python triager) Date: 2007-04-09 16:24
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.
msg52402 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-04-09 17:08
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.
msg52403 - (view) Author: Paul Boddie (pboddie) Date: 2007-04-09 19:51
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.
msg52404 - (view) Author: Josiah Carlson (josiahcarlson) * (Python triager) Date: 2007-04-09 20:06
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)'.
msg52405 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-04-09 20:41
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.
msg52406 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2007-04-14 07:42
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).
msg62136 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-02-07 06:25
Py2.6 and Py3.0 now how have tuple.index() and tuple.count().
History
Date User Action Args
2008-02-07 06:25:40rhettingersetstatus: open -> closed
resolution: out of date
messages: + msg62136
2007-09-20 16:42:42georg.brandlsettype: enhancement
components: + Interpreter Core, - None
versions: + Python 2.6, Python 3.0
2007-04-08 14:35:47pboddiecreate