[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

AltStyle によって変換されたページ (->オリジナル) /