[Python-Dev] string.find() again (was Re: timsort for jython)

[Guido van Rossum]

> [GvR]
> > > I personally see no way to defend ('' in 'x') returning false;
> > > it's so clearly a substring that any definition of
> > > substring-ness that excludes this seems mathematically wrong,
> > > despite your good intentions.

[SteveH]
> If you are serious about this proposal then clearly it would be as
> well to have "in" agree with find(), and currently
> anystring.find('') returns zero, suggesting the null string first
> appears at the beginning.

Yes, consistency strongly suggests that.

> > However, the backwards compatibility argument makes sense.  It used to
> > raise an exception and it would probably break code if it stopped
> > doing so; longer strings are much less likely to be passed by accident
> > so the need for the exception there is less strong.  I'm of two minds
> > on this now...
> 
> However, I'm somewhat horrified to see this being discussed
> seriously. You can take pragmatism too far, you know ;-)
> 
> Are you also proposing to allow
> 
>     if [2, 3] in [1, 2, 3, 4]
> 
> which is effectively the meaning you seem to be proposing for
> strings?

No, since it's not a common thing to need.

> Where else in the language does the keyword "in" refer to anything
> other than membership?

Dictionary keys?  That's certainly something very different from
sequence membership!

> Why do we need another way to do what find() and index() already do?

You must've missed the earlier thread -- it's because a substring test
is a common operation and the way to spell it with find() requires you
to tack on ">= 0" which many people accidentally leave out when in a
hurry.

> Should we also ensure that
> 
>     for s in "abc":
>         print s
> 
> prints
> 
>     a
>     ab
>     abc
>     b
>     bc
>     c
> 
> Should it also print a blank line because "'' in anystring" is true? I can
> see why users might want to be able to use a "string in string" construct,
> but it would seem to confuse the "for" semantics. Is there some other
> construct for which
> 
>     for v in object_or_instance:
> 
> does not assign to v all x such that "x in object_or_instance" is true? I
> can see a few teaching problems here.

To this latter example I can only say, "A foolish consistency is the
hobgoblin of little minds."

At least this still holds (unless x is an iterator or otherwise
mutated by access :-):

  for v in x:
     assert v in x

--Guido van Rossum (home page: http://www.python.org/~guido/)