On 8/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
[snip]
[snip]
"Guido van Rossum" <[EMAIL PROTECTED]> 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]
- Josiah
_______________________________________________
Python-3000 mailing list
[email protected]
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.
- Brian
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
