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

[Josiah Carlson]

"Fredrik Lundh" <fredrik at pythonware.com> wrote:
> 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?

I would argue no.  Based on my experience with find, I would expect that
find produces values >= start, except when not found, then -1. (note
that I am talking about find and not rfind)


> 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)?

Return value boundaries seem the more appealing of the two.

 - Josiah