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

[Terry Reedy]

"Josiah Carlson" <jcarlson at uci.edu> wrote in message 
news:20050826134317.7DFD.JCARLSON at uci.edu...
>
> "Terry Reedy" <tjreedy at udel.edu> wrote:
>>
>> Can str.find be listed in PEP 3000 (under builtins) for removal?

Guido has already approved, but I will try to explain my reasoning a bit 
better for you.  There are basically two ways for a system, such as a 
Python function, to indicate 'I cannot give a normal response."  One (1a) 
is to give an inband signal that is like a normal response except that it 
is not (str.find returing -1).  A variation (1b) is to give an inband 
response that is more obviously not a real response (many None returns). 
The other (2) is to not respond (never return normally) but to give an 
out-of-band signal of some sort (str.index raising ValueError).

Python as distributed usually chooses 1b or 2.  I believe str.find and 
.rfind are unique in the choice of 1a.  I am pretty sure that the choice 
of -1 as error return, instead of, for instance, None, goes back the the 
need in static languages such as C to return something of the declared 
return type.  But Python is not C, etcetera.  I believe that this pair is 
also unique in having exact counterparts of type 2.  (But maybe I forgot 
something.)

>> Would anyone really object?

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

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.

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

So are you advocating D above or claiming that substring indexing is 
uniquely deserving of having two versions?  If the latter, why so special? 
If we only has str.index, would you actually suggest adding this particular 
duplication?

> Considering the apparent dislike/hatred for str.find.

I don't hate str.find.  I simply (a) recognize that a function designed for 
static typing constraints is out of place in Python, which does not have 
those constraints and (b) believe that there is no reason other than 
history for the duplication and (c) believe that dropping .find is 
definitely better than dropping .index and changing .find.

> Would you further request that .rfind be removed from strings?

Of course.  Thanks for reminding me.

>  The inclusion of .rindex?

Yes, the continued inclusion of .rindex, which we already have.

Terry J. Reedy