Home Original page

[Python-ideas] Deprecate str.find

Ethan Furman ethan at stoneleaf.us
Sat Jul 16 17:46:04 CEST 2011 
Raymond Hettinger wrote:
> 
> On Jul 15, 2011, at 6:57 AM, Mike Graham wrote:
> 
>> str.find (and bytes.find) is worse than the alternatives in every way.
>> It should be explicitly deprecated in favour of str.__contains__ and
>> str.index.
> 
> Unless an API is flat out broken, deprecation is almost always a bad idea.
> This API has been around for a very long time, so deprecating it will
> break lots of people's code for almost zero benefit:
> 
> http://www.google.com/codesearch#search/&q=%5C.find%5C(%20lang:%5Epython$&type=cs 
> <http://www.google.com/codesearch#search/&q=%5C.find%5C(%20lang:%5Epython$&type=cs>


How ironic that the fist hit seems to display the problem Mike is 
concerned with:

         position =  min(position, len(self.contents))
         if hasattr(newChild, 'parent') and newChild.parent != None:
             # We're 'inserting' an element that's already one
             # of this object's children.
             if newChild.parent == self:
                 index = self.find(newChild)
                 if index and index < position:
                     # Furthermore we're moving it further down the
                     # list of this object's children. That means that
                     # when we extract this element, our target index
                     # will jump down one.
                     position = position - 1

I haven't read all the surrounding code to know if this will ever fail, 
but the whole 'index = ... .find(...); if index and ...' certainly 
doesn't lend confidence.  After all, if you *know* newChild is in self, 
why not use .index()?

~Ethan~
More information about the Python-ideas mailing list