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

["Martin v. Löwis"]

Terry Reedy wrote:
> One (1a) 
> is to give an inband signal that is like a normal response except that it 
> is not (str.find returing -1).
> 
> Python as distributed usually chooses 1b or 2.  I believe str.find and 
> .rfind are unique in the choice of 1a.

That is not true. str.find's choice is not 1a, and there are other
functions which chose 1a): -1 does *not* look like a normal response,
since a normal response is non-negative. It is *not* the only method
with choice 1a): dict.get returns None if the key is not found, even
though None could also be the value for the key.

For another example, file.read() returns an empty string at EOF.


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

dict.__getitem__ is a counterpart of type 2 of dict.get.

> So, I wonder, what is your favored alternative?
> 
> A. Status quo: ignore the opportunity to streamline the language.

My favourite choice is the status quo. I probably don't fully
understand the word "to streamline", but I don't see this as
rationalizing. Instead, some applications will be more tedious
to write.

> So are you advocating D above or claiming that substring indexing is 
> uniquely deserving of having two versions?  If the latter, why so special? 

Because it is no exception that a string is not part of another string,
and because the question I'm asking "is the string in the other string,
and if so, where?". This is similar to the question "does the dictionary
have a value for that key, and if so, which?"

> If we only has str.index, would you actually suggest adding this particular 
> duplication?

That is what happened to dict.get: it was not originally there (I
believe), but added later.

Regards,
Martin