[Python-ideas] Deprecate str.find

[Raymond Hettinger]

On Jul 17, 2011, at 2:13 AM, Masklinn wrote:

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

There is a fundamental difference between content (values in the list)
and the list position.  There are meaningful search defaults for the
former but not the latter.  It's important that to grasp this distinction
before going further.


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

My reading is that not a single one of these entries has a signature with a user specifiable default value of arbitrary type.

IOW, there is nothing resembling proposal on the table.  AFAICT, all of them are equivalent to either our current str.find() or str.index().


Raymond