Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
[Fredrik Lundh]
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...
FWIW, I like what you eventually did:
"ab".find("") 0 "ab".find("", 1) 1 "ab".find("", 2) 2 "ab".find("", 3) -1 "ab".rfind("") 2 "ab".rfind("", 1) 2 "ab".rfind("", 2) 2 "ab".rfind("", 3) -1
I don't know that a compelling argument can be made for such a seemingly senseless operation, but the behavior above is at least consistent with the rule that a string of length n has exactly n+1 empty substrings, at 0:0, 1:1, ..., and n:n.
On 5/31/06, Tim Peters
[Fredrik Lundh]
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...
FWIW, I like what you eventually did:
"ab".find("") 0 "ab".find("", 1) 1 "ab".find("", 2) 2 "ab".find("", 3) -1 "ab".rfind("") 2 "ab".rfind("", 1) 2 "ab".rfind("", 2) 2 "ab".rfind("", 3) -1
I don't know that a compelling argument can be made for such a seemingly senseless operation, but the behavior above is at least consistent with the rule that a string of length n has exactly n+1 empty substrings, at 0:0, 1:1, ..., and n:n.
Yes. Bravo! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum -
Tim Peters