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

Brian Holmes holmesbj.dev at gmail.com
Wed Aug 23 08:46:22 CEST 2006

On 8/22/06, Jack Diederich <jack at psynchronous.com> 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.

More information about the Python-3000 mailing list