"Fredrik Lundh" <[EMAIL PROTECTED]> 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 _______________________________________________ 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