[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