[GvR]
> > [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.
>
And of course, that wouldn't be a foolish consistency :-)
> > > 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...
> >
[ ... ]
> > 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.
>
Nope, I didn't miss it. As I said, I just found it hard to believe this was
a serious discussion.
> > 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."
>
Of course the string has always been an anomalous sequence anyway, but it
seems to be becoming less of a sequence.
> At least this still holds (unless x is an iterator or otherwise
> mutated by access :-):
>
> for v in x:
> assert v in x
>
Indeed. A rather weaker assertion, though. Anyhoo, no other arguments
against s1 in s2, so I'll make one parting comment. While I understand
perfectly well the pragmatic case for this change, it appears to blur the
borders between set membership and subsetting; if it's so desirable, why
didn't the need arise earlier?.
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4