[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):
try:
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)
str.register(find)
>>> "abcdabc".find("bc")
1
Now find() can be stored in a pure Python module without maintaining it
on interpreter level ( same as with reduce, map and filter ).
Kay
More information about the Python-Dev
mailing list