[Python-ideas] Deprecate str.find

[Masklinn]

On 2011-07-17, at 10:09 , Raymond Hettinger wrote:
> On Jul 17, 2011, at 12:15 AM, Nick Coghlan wrote:
>> 
>> Indeed, the problem as I see it is that our general idiom for
>> functions and methods that raise 'Not Found' exceptions is to accept
>> an optional parameter that specifies a value to return in the Not
>> Found case.
> 
> There's a difference between methods that return looked-up values
> (where a default might make sense) versus a method that returns
> an index (where it usually makes no sense at all).
Why not? An index is a looked-up value here (it's just a reverse lookup)
and .find is returning a (non-configurable) default value is it not?

> * Take a look at what other languages do.  Practically every general
> purpose language has an API for doing substring searches.  Since
> we're not blazing new territory here, there needs to be a good precedent
> for this change (no shooting from the hip when the problem has already
> been well solved many times over).
Other languages do everything and their reverse. You have languages
returning −1 or 0 (the latter for 1-indexed languages), languages
returning differently-typed sentinels, etc…

SML even returns the length of the string.

See a listing at http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)#Find

The most common behavior on the page does seem to be returning a
numerical sentinel. On the other hand, I'm not sure how many of these
languages return a sentinel value which is also a valid index.