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

[Guido van Rossum]

On 8/26/05, Terry Reedy <tjreedy at udel.edu> wrote:
> Can str.find be listed in PEP 3000 (under builtins) for removal?

Yes please. (Except it's not technically a builtin but a string method.)

> Would anyone really object?

Not me.

> Reasons:
> 
> 1. Str.find is essentially redundant with str.index.  The only difference
> is that str.index Pythonically indicates 'not found' by raising an
> exception while str.find does the same by anomalously returning -1.  As
> best as I can remember, this is common for Unix system calls but unique
> among Python builtin functions.  Learning and remembering both is a
> nuisance.
> 
> 2. As is being discussed in a current c.l.p thread, -1 is a legal indexing
> subscript.  If one uses the return value as a subscript without checking,
> the bug is not caught.  None would be a better return value should find not
> be deleted.
> 
> 3. Anyone who prefers to test return values instead of catch exceptions can
> write (simplified, without start,end params):
> 
> def sfind(string, target):
>   try:
>     return string.index(target)
>   except ValueError:
>     return None # or -1 for back compatibility, but None better
> 
> This can of course be done for any function/method that indicates input
> errors with exceptions instead of a special return value.  I see no reason
> other than history that this particular method should be doubled.

I'd like to add:

4. The no. 1 use case for str.find() used to be testing whether a
substring was present or not; "if s.find(sub) >= 0" can now be written
as "if sub in s". This avoids the nasty bug in "if s.find(sub)".

> If .find is scheduled for the dustbin of history, I would be willing to
> suggest doc and docstring changes.  (str.index.__doc__ currently refers to
> str.find.__doc__.  This should be reversed.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)