In article <[EMAIL PROTECTED]>, Terry Reedy <[EMAIL PROTECTED]> wrote:
> David C. Ullrich wrote: > > >>>> 'ab' in 'abc' > > True > > 'a' in 'abc' works according to the standard meaning of o in collection. > > 'ab' in 'abc' could not work by that standard meaning because strings, > as virtual sequences, only contain characters (length 1 strings). Among > built-in collections, this limitation is unique to strings (and bytes, > in 3.0). So in 2.3, 'in' was given a useful extension of meaning that > is also unique to strings (and bytes). Ah, I didn't realize that this was new. Thanks - at least this means I was right about the way it worked formerly. > >>>> [1,2] in [1,2,3] > > False > > [1,2] can be an member of tuples, lists, dicts and other general > collections. [1,2] in collection therefore has that meaning, that it is > a single element of collection. Extending the meaning would conflict > with this basic meaning. Well of course. > > Is there a reason for the inconsistency? I would > > have thought "in" would check for elements of a > > sequence, regardless of what sort of sequence it was... > > It is not an inconsistency but an extension corresponding to the > limitation of what an string element can be. It's an inconsistency. That doesn't mean it's a bad thing or that I want my money back. It may well be a reasonable inconsistency - strings _can_ work that way while it's clear lists had better not. But it's an inconsistency. > Terry J. Reedy -- David C. Ullrich -- http://mail.python.org/mailman/listinfo/python-list
