[Python-Dev] Remove str.find in 3.0?
jcarlson at uci.edu
Sat Aug 27 19:16:34 CEST 2005
Guido van Rossum <gvanrossum at gmail.com> wrote:
> On 8/26/05, Josiah Carlson <jcarlson at uci.edu> wrote:
> > Taking a look at the commits that Guido did way back in 1993, he doesn't
> > mention why he added .find, only that he did. Maybe it was another of
> > the 'functional language additions' that he now regrets, I don't know.
> There's nothing functional about it. I remember adding it after
> finding it cumbersome to write code using index/rindex. However, that
> was long before we added startswith(), endswith(), and 's in t' for
> multichar s. Clearly all sorts of varieties of substring matching are
> important, or we wouldn't have so many methods devoted to it! (Not to
> mention the 're' module.)
> However, after 12 years, I believe that the small benefit of having
> find() is outweighed by the frequent occurrence of bugs in its use.
Oh, there's a good thing to bring up; regular expressions! re.search
returns a match object on success, None on failure. With this "failure
-> Exception" idea, shouldn't they raise exceptions instead? And
goodness, defining a good regular expression can be quite hard, possibly
leading to not insignificant "my regular expression doesn't do what I
want it to do" bugs. Just look at all of those escape sequences and the
syntax! It's enough to make a new user of Python gasp.
Most of us are consenting adults here. If someone writes buggy code
with str.find, that is unfortunate, maybe they should have used regular
expressions and tested for None, maybe they should have used
str.startswith (which is sometimes slower than m == n[:len(m)], but I
digress), maybe they should have used str.index. But just because buggy
code can be written with it, doesn't mean that it should be removed.
Buggy code can, will, and has been written with every Python mechanism
that has ever existed or will ever exist.
With the existance of literally thousands of uses of .find and .rfind in
the wild, any removal consideration should be weighed heavily - which
honestly doesn't seem to be the case here with the ~15 minute reply time
yesterday (just my observation and opinion). If you had been ruminating
over this previously, great, but that did not seem clear to me in your
original reply to Terry Reedy.
More information about the Python-Dev