[Python-Dev] Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
Guido van Rossum
guido at python.org
Thu Jun 1 04:30:35 CEST 2006
More information about the Python-Dev mailing list
Thu Jun 1 04:30:35 CEST 2006
- Previous message: [Python-Dev] Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
- Next message: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/31/06, Tim Peters <tim.peters at gmail.com> wrote: > [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/)
- Previous message: [Python-Dev] Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
- Next message: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list