[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