[Python-ideas] Deprecate str.find
Raymond Hettinger
raymond.hettinger at gmail.com
Sun Jul 17 00:52:27 CEST 2011
On Jul 16, 2011, at 3:15 PM, Devin Jeanpierre wrote:
> Slicing was brought up as a use-case where you can use a default
> without checking.
This thread has lost contact with reality. It started with the
reasonable observation that many uses of str.find could
be replaced with a simple test using the in-operator.
Now, the thread is venturing into the typical python-ideas
world of making-up random use cases and APIs. Something
like str.find() is in many languages and it is definitely not the
norm for them to have found a need to both be able to
return -1 or to supply a default value.
As a Python teacher, speaker, and consultant, I have the
opportunity to see and review the code repositories for
many companies. I'm pretty sure that I've never seen
a utils module with the likes of:
def myfind(fullstring, substring, default=None):
i = fullstring.find(substring)
if i == -1 and default is not None:
return default
return i
When I start seeing people routinely using a helper function
like this, I'll start to believe that a str.find default value isn't silly.
Mike's initial post was well grounded in observations about
code that could be improved by using "in" or str.index() instead
of str.find(). Though I disagreed with the recommendation
to deprecate, it would be even worse to exacerbate the usability
issues by making the method signature even more complex
(with a new optional argument and a new signature variant
for the return value). That isn't progress. It's aspiring cruft
that makes the language harder to learn and remember.
Raymond
More information about the Python-ideas
mailing list