tuples, index method, Python's design

[Steven D'Aprano]

On Sun, 08 Apr 2007 20:10:21 -0400, Carsten Haese wrote:

> On Sun, 2007-04-08 at 13:10 -0700, Paul Rubin wrote:
>> Carsten Haese <carsten at uniqsys.com> writes:
>> > > Do you not see the gratuituous inconsistency between tuples and lists
>> > > as a useless feature?  What is the use case for keeping it?
>> > 
>> > When a new feature is requested, the burden of proof is on the requester
>> > to show that it has uses. The use case for not having tuple.index is
>> > that there are no use cases for having it. If that answer sounds absurd,
>> > it is because your question is absurd.
>> 
>> The use case has already been discussed.  Removing the pointless
>> inconsistency between lists and tuples means you can stop having to
>> remember it, so you can free up brain cells for implementing useful
>> things.  That increases your programming productivity.
> 
> Will tuples also get a sort method? What about append and extend? pop?
> __iadd__? __delslice__?

Since tuples are immutable, no.

And before you ask, since they aren't strings, they won't get upper,
lower, split or strip either.

 
> How many brain cells are actually freed up by not having to remember
> that *one* method that you'd never use doesn't exist?

74,972,561.


I think the problem is that Python developers are split between those who
see tuples as immutable lists, and those who see them as records/structs.
Neither of them is wrong -- tuples are multi-use. Guido may or may not
have designed them to be used as structs (short and heterogeneous, as
opposed to long and homogeneous) but designers are often surprised by the
uses people find for their creations, and the designer doesn't get the
final say as to what is the "right" usage.

If you see tuples as an immutable list, having an index method is quite
useful. If you see them as structs, an index method is useless.



-- 
Steven.