On 2007-04-11, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "BJrn Lindqvist" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: >> 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. > > 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. > >======================= > It would be ambiguous: [3,4] in [[1,2], [3,4], [5,6]] is True now. > > Strings are special in that s[i] can only be a (sub)string of length 1. > 'b' in 'abc' is True. This makes looking for longer substrings easy. > > However, [2] in [1,2,3] is False. IE, list[i] is not normally a list. So > looking for sublists is different from looking for items.
Well I think this illustrates nicely what can happen if you design by use cases. Let us assume for a moment that finding out if one list is a sublist of a second list gets considered something usefull enough to be included in Python. Now the in operator can't be used for this because it would create ambiguities. So it would become either a new operator or a new method. But whatever the solution it would be different from the string solution. Now if someone would have thought about how "st1 in st2" would generalize to other sequemce if st1 contained more than one character they probably would have found the possible inconsistency that could create and though about using an other way than using the in-operator for this with strings. A way that wouldn't create ambiguities when it was considered to be extended to other sequences. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
