[Python-Dev] Remove str.find in 3.0?

Kay Schluehr kay.schluehr at gmx.net
Sat Aug 27 14:57:08 CEST 2005

Terry Reedy wrote:

>>I would object to the removal of str.find().
> So, I wonder, what is your favored alternative?
> A. Status quo: ignore the opportunity to streamline the language.

I actually don't see much benefits from the user perspective. The 
discourse about Python3000 has shrunken from the expectation of the 
"next big thing" into a depressive rhetorics of feature elimination.
The language doesn't seem to become deeper, smaller and more powerfull 
but just smaller.

> B. Change the return type of .find to None.
> C. Remove .(r)index instead.
> D. Add more redundancy for those who do not like exceptions.

Why not turning index() into an iterator that yields indices 
sucessively? From this generalized perspective we can try to reconstruct 
behaviour of Python 2.X.

Sometimes I use a custom keep() function if I want to prevent defining a 
block for catching StopIteration. The keep() function takes an iterator 
and returns a default value in case of StopIteration:

def keep(iter, default=None):
         return iter.next()
     except StopIteration:
         return default

Together with an index iterator the user can mimic the behaviour he 
wants. Instead of a ValueError a StopIteration exception can hold as
an "external" information ( other than a default value ):

 >>> keep( "abcdabc".index("bc"), default=-1)  # current behaviour of the
                                               # find() function
 >>> (idx for idx in "abcdabc".rindex("bc"))   # generator expression

Since the find() method acts on a string literal it is not easy to
replace it syntactically. But why not add functions that can be hooked 
into classes whose objects are represented by literals?

def find( string, substring):
     return keep( string.index( substring), default=-1)


 >>> "abcdabc".find("bc")

Now find() can be stored in a pure Python module without maintaining it 
on interpreter level ( same as with reduce, map and filter ).


More information about the Python-Dev mailing list