On 8/22/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
On Tue, Aug 22, 2006 at 06:32:39PM -0700, Guido van Rossum 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?
Looking at my own code I use find() in two cases
1) in an "if" clause where "in" or startswith() would be appropriate
This code was written when I started with python and is closer to
C++ or perl or was a literal translation of a snippet of C++ or perl
2) where try/except around index() would work just fine and partition
would be even better. eg/
try:
parts.append(text[text.index('himom')])
except ValueError: pass
This is 50 uses of find/rfind in 70 KLOCs of python. Considering I would
be better off not using find() in the places I do use it I would be happy
to see it go.
-Jack
_______________________________________________
Even after reading Terry Reedy's arguments, I don't see why we need to remove this option. Let both exist. I'd prefer grandfathering something like this and leaving it in, even if it wouldn't be there had known everything from the start.
I just don't think its worth causing people grief in porting to Py3k for something so trivial. I support fixing things in Py3k that are real improvements, but this doesn't really seem like its worth the trade off.
- 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
