[Python-3000] Droping find/rfind? (original) (raw)

Brian Holmes holmesbj.dev at gmail.com
Wed Aug 23 08:50:53 CEST 2006

On 8/22/06, Josiah Carlson <jcarlson at uci.edu> wrote:

"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?

[snip]

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.

[snip]

Python-3000 mailing list Python-3000 at python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/holmesbj.dev%40gmail.com

+1

I think that would make a great addition to Py3k, or even 2.6.

More information about the Python-3000 mailing list