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