why not "'in' in 'in'"?

[Grant Griffin]

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:
	   ...

to:

	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:

	if email_subject.find('mortage'):
           ...

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.

if-i-were-highly-trainable-i'd-be-using-perl-<wink>-ly y'rs,

=g2
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation            http://www.iowegian.com