Armin Rigo wrote:
> Ah, it's a corner case of str.find() whose behavior just changed.
> Previously, 'abc'.find('', 100) would return -1, and now it returns 100.
> Just to confuse matters, the same test with unicode returns 100, and has
> always done so in the past. (Oh well, one of these again...)
>
> So, we need to decide which behavior is "right". One could argue that
> the current 2.5 HEAD now has a consistent behavior, so it could be kept;
> but there is an opposite argument as well, which is that some existing
> programs like the one I was testing are now thrown into annoying
> infinite loops because str.find() never returns -1 any more, even with
> larger and larger start arguments. I believe that it's a pattern that
> could be common in string-processing scripts, trying to match substrings
> at various points in a string trusting that str.find() will eventually
> return -1.
well, the empty string is a valid substring of all possible strings
(there are no "null" strings in Python). you get the same behaviour
from slicing, the "in" operator, "replace" (this was discussed on the
list last week), "count", etc.
if you're actually searching for a *non-empty* string, find() will
always return -1 sooner or later.
> Hum, my apologies for my grumpy comments about the NFS sprint. At
> least, the unification of the string and unicode algorithm that was
> started there is a good move, also because it exposes pre-existing
> inconsistencies.
here's my current favourite:
>>> "abc".count("", 100)
-96
</F>
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