why not "'in' in 'in'"?
not.this at seebelow.org
Thu Jun 13 15:42:57 CEST 2002
Erik Max Francis wrote:
> Grant Griffin wrote:
> > In that case, perhaps I should have thought of a better one <wink>.
> > In
> > any event, in the case of strings, I think one might stretch the
> > concept
> > of "membership" to include substrings. In fact, note that since
> > Python
> > has no actual character type (because a character is adequately
> > represented as a string of length one) the "in" operator actually
> > _does_
> > test membership of strings in strings. But for some reason, it's
> > limited to testing strings of length one. Go figure!
> A string is a sequence of one-character strings. It's not a sequence of
> all the subsequences of a string.
> > Honest answer: although I can't see much use for that construct, I
> > can't
> > see much harm in it either. So although it's probably not worth
> > adding
> > to Python, I'm sure _somebody_ would find a use for it.
> But that's exactly the problem; if you want [1, 2] in [1, 2, 3, 4] to
> return true (i.e., for the `in' operator to test substrings, not just
> membership), then you have an ambiguity problem. A list can contain
> sublists as elements, after all.
> > But anyway, let's "just say no" to the tuple case rather than confuse
> > ourselves; let's just make the string version of "in" a special case.
> Why make a special case for it when string.find and S.find already exist
> and are included expressly for that purpose?
Again, it has to do with the fact that the illegal multi-character "in"
is intuitive and reads better. Compare the following:
if 'mortgage' in email_subject:
if email_subject.find('mortgage') >= 0:
I consider the former to be highly practical, if not highly pure.
As to the latter, I frequently made this mistake at first:
which is fairly intutitive, but doesn't work, of course, because "find"
returns -1 (logical true) in the failure case! That in itself is
counter-intuitive--though it makes sense in the context of "find" being
intended as a position detector, not a substring tester. (Maybe it
should have been called "position" instead...) But the very fact that a
failed "find" returns true suggests that we're on the wrong path--at
least as far as intuition/readability goes.
Originally, I would find myself automatically typing the illegal "in"
form (because it's highly intuitive, though illegal), but by now I've
nearly trained myself to type the "find" form. But even so, I find it
somewhat hard to read.
Grant R. Griffin g2 at dspguru.com
Publisher of dspGuru http://www.dspguru.com
Iowegian International Corporation http://www.iowegian.com
More information about the Python-list