On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: > Paul Boddie wrote: > > On 10 Apr, 11:48, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >> On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: > >> > >>> 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" > > > > I think this observation leads to insights both at the end-user level > > and at the implementer level. Tuples and lists are sequences; the > > index method can be defined generically for all sequences; adding such > > a method to the tuple type can be done with barely any changes to the > > implementation taken from the list type. This leads to the observation > > that a generic index method (defined as a function in the > > implementation) could be made to work with both lists and tuples, and > > that various other methods might also be defined similarly, although > > things like append, extend and other mutating methods wouldn't be > > appropriate for a tuple. > > > A generic definition of index would be tricky, though, if you wanted to > include strings as sequences. In that case you aren't testing for the > presence of a single element but a sub-sequence - I think this change > was introduced in 2.4 to allow checks like > > "men" in "three good men" > > to succeed where formerly only single characters could be checked for. > One might perversely allow extension to lists and tuples to allow > > [3, 4] in [1, 2, 3, 4, 5, 6] > > to succeed, but that's forcing the use case beyond normal limits. The > point I am trying to make is that circumstances alter cases, and that we > can't always rely on our intuition to determine how specific methods > work, let alone whether they are available.
I'd love to have that! There are at least one million use cases for finding a sequence in a sequence and implementing it yourself is non-trivial. Plus then both list and tuple's index methods would work *exactly* like string's. It would be easier to document and more useful. A big win. > Indeed the syntax is deliberately "crippled" - Guido's reasoning being, > I believe, that if it were too easy and natural to use then people would > use it inappropriately and too frequently. There are no appropriate use cases for that feature. Maybe not for tuple.index either, but increasing consistency and being able to say "ALL sequences have an index method that works like THIS" would be a big win. Unfortunately, it really is the string type that screws up the symmetry. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
