[Python-Dev] Remove str.find in 3.0?

[Josiah Carlson]

Donovan Baarda <abo at minkirri.apana.org.au> wrote:
> 
> On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote:
> > Guido van Rossum <gvanrossum at gmail.com> wrote:
> [...]
> > 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.
> 
> I think re.match() returning None is an example of 1b (as categorised by
> Terry Reedy). In this particular case a 1b style response is OK. Why;

My tongue was firmly planted in my cheek during my discussion of regular
expressions.  I was using it as an example of when one starts applying
some arbitrary rule to one example, and not noticing other examples that
do very similar, if not the same thing.

[snip discussion of re.match, re.search, str.find]

If you are really going to compare re.match, re.search and str.find, you
need to point out that neither re.match nor re.search raise an exception
when something isn't found (only when you try to work with None).  This
puts str.index as the odd-man-out in this discussion of searching a
string - so the proposal of tossing str.find as the 'weird one' is a
little strange.



One thing that has gotten my underwear in a twist is that no one has
really offered up a transition mechanism from "str.find working like now"
and some future "str.find or lack of" other than "use str.index". 
Obviously, I personally find the removal of str.find to be a nonstarter
(don't make me catch exceptions or use regular expressions when both are
unnecessary, please), but a proper transition of str.find from -1 to
None on failure would be beneficial (can which one be chosen at runtime
via __future__ import?).

During a transition which uses __future__, it would encourage the
/proper/ use of str.find in all modules and extensions in which use it...

    x = y.find(z)
    if x >= 0:
        #...

Forcing people to use the proper semantic in their modules so as to be
compatible with other modules which may or may not use str.find returns
None, would (I believe) result in an overall reduction (if not
elimination) of bugs stemming from str.find, and would prevent former
str.find users from stumbling down the try/except/else misuse that Tim
Peters highlighted.

Heck, if you can get the __future__ import working for choosing which
str.find to use (on a global, not per-module basis), I say toss it into
2.6, or even 2.5 if there is really a push for this prior to 3.0 .

 - Josiah