[Python-Dev] Let's stop eating exceptions in dict lookup

Fredrik Lundh fredrik at pythonware.com
Tue May 30 13:05:55 CEST 2006


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> 





More information about the Python-Dev mailing list