[Python-Dev] Remove str.find in 3.0?
tjreedy at udel.edu
Sat Aug 27 03:07:46 CEST 2005
"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
>> 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
> 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
More information about the Python-Dev