Tim Peters wrote:
>>>> "abc".count("", 100)
> 1
>>>> u"abc".count("", 100)
> 1
which is the same as
>>> "abc"[100:].count("")
1
>>>> "abc".find("", 100)
> 100
>>>> u"abc".find("", 100)
> 100
>
> today, although the idea that find() can return an index that doesn't
> exist in the string is particularly jarring. Since we also have:
>
>>>> "abc".rfind("", 100)
> 3
>>>> u"abc".rfind("", 100)
> 3
>
> it's twice as jarring that "searching from the right" finds the target
> at a _smaller_ index than "searching from the left".
well, string[pos:pos+len(substring)] == substring is true in both cases.
would "abc".find("", 100) == 3 be okay? or should we switch to treating the
optional
start and end positions as "return value boundaries" (used to filter the
result) rather than
"slice directives" (used to process the source string before the operation)?
it's all trivial
to implement, and has no performance implications, but I'm not sure what the
consensus
really is...
</F>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
