tuples, index method, Python's design

[Antoon Pardon]

On 2007-04-10, Duncan Booth <duncan.booth at invalid.invalid> wrote:
> 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.

So what is the easiest to learn: "All sequences have an index method" or
"Such and so sequences have an index method and others don't"

Which of the above is the easiest to document?

Now with implementation and maintaining. If you would start with a class
of sequence which classes like tuple and list would inherit from, then
there also would be a single function to be implemented and maintained.
It would just be usable in more types.

>>> 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.

If someone states: "Show me your use case for using tuple.index and I
will show you how to avoid it." or words to that effect I think there
is little use trying.

Besides I have seen how such things evolve here before. Every use case
that will be presented, will be rewritten in a way that doesn't need
tuple.index and these rewritals will be used as an argument for not
having tuple.index. If you need to hash it, you can simply subclass
list and provide a hash with your class or you can simply use tuples
and write an index function yourself.

The same happened with the ternary operator. Every use case someone
could come up with was rejected by rewriting the code without using
a ternary operator. AFAICS the only reason the ternary operator
finaly got introduced was because a python developer was bitten by an
illusive bug, introduced by one of the idioms that was often used as a
way to simulate a ternary operator.

-- 
Antoon Pardon