"Terry Reedy" <tjreedy@udel.edu> wrote:
Can str.find be listed in PEP 3000 (under builtins) for removal? Would anyone really object?
I would object to the removal of str.find() . In fact, older versions of Python which only allowed for single-character 'x in str' containment tests offered 'str.find(...) != -1' as a suitable replacement option, which is found in the standard library more than a few times... 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). I've been thinking for years that .find should be part of the set of operations offered to most, if not all sequences (lists, buffers, tuples, ...). Considering the apparent dislike/hatred for str.find, it seems I was wise in not requesting it in the past.
Reasons:
1. Str.find is essentially redundant with str.index. The only difference is that str.index Pythonically indicates 'not found' by raising an exception while str.find does the same by anomalously returning -1. As best as I can remember, this is common for Unix system calls but unique among Python builtin functions. Learning and remembering both is a nuisance.
So pick one and forget the other. I think of .index as a list method (because it doesn't offer .find), not a string method, even though it is.
2. As is being discussed in a current c.l.p thread, -1 is a legal indexing subscript. If one uses the return value as a subscript without checking, the bug is not caught. None would be a better return value should find not be deleted.
And would break potentially thousands of lines of code in the wild which expect -1 right now. Look in the standard library for starting examples, and google around for others.
3. Anyone who prefers to test return values instead of catch exceptions can write (simplified, without start,end params):
def sfind(string, target): try: return string.index(target) except ValueError: return None # or -1 for back compatibility, but None better
This can of course be done for any function/method that indicates input errors with exceptions instead of a special return value. I see no reason other than history that this particular method should be doubled.
I prefer my methods to stay on my instances, and I could have sworn that the string module's functions were generally deprecated in favor of string methods. Now you are (implicitly) advocating the reversal of such for one method which doesn't return an exception under a very normal circumstance. Would you further request that .rfind be removed from strings? The inclusion of .rindex? - Josiah