[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

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