tuple.index() and tuple.count()

[hall.jeff at gmail.com]

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() )