[Python-3000] Droping find/rfind?

[Josiah Carlson]

"Guido van Rossum" <guido at python.org> wrote:
> At today's sprint, one of the volunteers completed a patch to rip out
> find() and rfind(), replacing all calls with index()/rindex(). But now
> I'm getting cold feet -- is this really a good idea? (It's been listed
> in PEP 3100 for a long time, but I haven't thought about it much,
> really.)
> 
> What do people think?

I have code for Python 2.x that uses [r]find, but have been
transitioning some of it to use [r]partition instead (writing
implementations based on [r]find, but it could have just as easily used
[r]split). Ultimately I think that an unambiguous 'find without slicing'
is useful.

One of the issues with the -1 return on find failure is that it is
ambiguous, one must really check for a -1 return. Here's an API that is
non-ambiguous:
    x.search(y, start=0, stop=sys.maxint, count=sys.maxint)

Which will return a list of up to count non-overlapping examples of y in
x from start to stop.  On failure, it returns an empty list.  This
particular API is at least as powerful as the currently existing [r]find
one, is unambiguous, etc.  It also has a not accidental similarity to
x.split(y, count=sys.maxint), which has served Python for quite a while,
though this would differ in that rather than always returning a list of
at least 1, it could return an empty list.

Its functionality is somewhat mirrored by re.finditer, but the above
search function can be easily turned into rsearch, whereas re is
forward-only.

If I were in a position to suggest a change, I would agree with Tim's
feeling that [r]index should go before [r]find, but I also think that 
[r]find could be made unambiguous; the above being an example of such,
but one that I'm not going to push for except as an example unambiguous
implementation.

 - Josiah