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