Antoon Pardon <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
