[Python-3000] Droping find/rfind?
jcarlson at uci.edu
Wed Aug 23 21:56:21 CEST 2006
"Steven Bethard" <steven.bethard at gmail.com> wrote:
> Steven Bethard wrote:
> > Could you post a simple example or two?
> Josiah Carlson wrote:
> > index = text.find(...)
> > if index >= 0:
> > ...
> > index = 0
> > while 1:
> > index = text.find(..., index)
> > if index == -1:
> > break
> > ...
> Thanks. So with your search() function, these would be something like:
> indices = text.search(pattern, count=1)
> if indices:
> index, = indices
> for index in text.search(pattern):
> if I understood the proposal right.
Yes, you understood my (strawman) proposal correctly. The former could
even be shortened to:
for index in text.search(pattern, count=1):
... if there wasn't an else clause in the original search. Note that my
point in the proposing of search was to say:
1. [r]index is cumbersome
2. [r]find can be error-prone for newbies due to the -1 return
3. the functionality seems to be useful (otherwise neither would exist)
4. let us unambiguate [r]find if possible, because it is the better of
the two (in my opinion)
5. or instead of 4, replace both of them with searh
People seem to like the #5 option, even though it was not my intent by
posting search originally. Given that some people like it, I'm now of
the opinion that if [r]find is going, then certainly [r]index should go
because it suffers from being more cumbersome to use and has a similar
class of bugs, and if both go, then we should have something to replace
them. As a replacement, search lacks the exception annoyance of index,
has an unambiguous return value, and naturally supports iterative find
Given search as a potential replacement, about the only question is
whether count should default to sys.maxint or 1. The original
description included count=sys.maxint, but if we want to use it as a
somewhat drop-in replacement for find and index, then it would make more
sense for it to have count=1 as a default, with some easy to access
count argument to make it find all of them.
More information about the Python-3000