Before the inevitable response comes, let me assure you I've read through the posts from Guido about this. 7 years ago Guido clearly expressed a displeasure with allowing these methods for tuple. Let me lay out (in a fresh way) why I think we should reconsider.
1) It's counterintuitive to exclude them: It makes very little sense why an indexable data structure wouldn't have .index() as a method. It makes even less sense to not allow .count() 2) There's no technical reason (that I'm aware of) why these can't be added 3) It does not (contrary to one of Guido's assertions) require any relearning of anything. It's a new method that could be added without breaking any code whatsoever (there isn't even a UserTuple.py to break) 4) The additional documentation is relatively minute (especially since it could be copied and pasted virtually verbatim from the list methods 5) It's MORE Pythonic to do it this way (more intuitive, less boilerplate) 6) It jives with the help file better. One of Guido's many stated reasons was that tuples are for heterogeneous sequences and lists are for homogeneous sequences. While this may be hypothetically true, the help file does not come close to pointing you in this direction nor does the implementation of the language. example: "Tuples have many uses. For example: (x, y) coordinate pairs, employee records from a database, etc. Tuples, like strings, are immutable: it is not possible to assign to the individual items of a tuple (you can simulate much of the same effect with slicing and concatenation, though). It is also possible to create tuples which contain mutable objects, such as lists." is a quote from the help file. Not only does it never mention homogeneous vs. heterogeneous but mentions both immutable and mutable which draws your mind and attention to that aspect. While tuples and lists may have different uses based on convention, there's really only two reasons to ever use a tuple: Efficiency or dictionary keys (or some similar immutability requirement). The implementation contains absolutely NOTHING to reinforce the idea that lists are for homogeneous data. The implementation of the language contains EVERY indication that tuples are second class citizens only to be used for those limited functions above (in fact, efficiency isn't even talked about in the documentation... I pieced that together from other threads). Tuples could have been implemented as frozenlist just as easily. The lack of .index() and .count() appears to be primarily motivated by a subtle and silent (at least in the documentation) desire to push towards coding "best practice" rather than for any technical reason. While I'm certainly not a "change for change sake" kind of guy and I understand the "bang for your buck" thinking, I'm just not seeing the rational for stopping this so forcibly. I get the impression that if a perfect working patch was submitted, Guido might still reject it which just seems odd to me. Again, I'm not trying to raise a stink or open old wounds, I just ran across it in an app, started doing some research and was thoroughly confused (for the record, I'm using the tuples as dictionary keys and had a desire to do k.count() for some edit checks and realized I had to convert the thing to a list first to run count() ) -- http://mail.python.org/mailman/listinfo/python-list
