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

[Josiah Carlson]

"Terry Reedy" <tjreedy at udel.edu> wrote:
> 
> Can str.find be listed in PEP 3000 (under builtins) for removal?
> Would anyone really object?

I would object to the removal of str.find() .  In fact, older versions
of Python which only allowed for single-character 'x in str' containment
tests offered 'str.find(...) != -1' as a suitable replacement option,
which is found in the standard library more than a few times...

Further, forcing users to use try/except when they are looking for the
offset of a substring seems at least a little strange (if not a lot
braindead, no offense to those who prefer their code to spew exceptions
at every turn).

I've been thinking for years that .find should be part of the set of
operations offered to most, if not all sequences (lists, buffers, tuples, ...). 
Considering the apparent dislike/hatred for str.find, it seems I was
wise in not requesting it in the past.

> 
> 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.

So pick one and forget the other.  I think of .index as a list method 
(because it doesn't offer .find), not a string method, even though it is.

> 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.

And would break potentially thousands of lines of code in the wild which
expect -1 right now.  Look in the standard library for starting examples,
and google around for others.

> 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 prefer my methods to stay on my instances, and I could have sworn that
the string module's functions were generally deprecated in favor of
string methods.  Now you are (implicitly) advocating the reversal of
such for one method which doesn't return an exception under a very
normal circumstance.

Would you further request that .rfind be removed from strings?  The
inclusion of .rindex?

 - Josiah