[Python-3000] Droping find/rfind?
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?
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
> 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
> Python-3000 mailing list
> Python-3000 at python.org
I think that would make a great addition to Py3k, or even 2.6.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000