tuples, index method, Python's design

[Duncan Booth]

Antoon Pardon <apardon at forel.vub.ac.be> wrote:

>> When a new feature is requested, the burden of proof is on the requester
>> to show that it has uses.
> 
> I don't agree. Good or bad design is not dependant on what is
> implemented and what is not.

There is a cost to every new language feature: it has to be implemented, 
documented, maintained, and above all learned by the users. Good design 
involves, in part, not adding to these burdens except where there is a 
benefit at least equal to the cost.

>> 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.
> 
> You mean that those who are against tuple.index won't find any use case
> convincing enough.
> 
Why not try them? Pose a few useful cases where the existence of 
tuple.index() would actually give a benefit and see what response you get.

You would have to meet a few obvious conditions: the use case would need to 
be one where a tuple was preferable to a list (the obvious one being where 
you need to hash it), the tuple would have to be sufficiently long or the 
calls to 'index' sufficiently frequent to make casting to a list so you can 
call 'list(obj).index(...)' unattractive, and you actually need a reason to 
be using 'index' rather than just the 'in' operator.