"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Terry Reedy" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
