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

[Josiah Carlson]

Steve Holden <steve at holdenweb.com> wrote:
> 
> Josiah Carlson wrote:
> > Donovan Baarda <abo at minkirri.apana.org.au> wrote:
> [...]
> > 
> > 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:
> >         #...
> > 
> It does seem rather fragile to rely on the continuation of the current 
> behavior
> 
>   >>> None >= 0
> False

Please see this previous post on None comparisons and why it is unlikely
to change:
http://mail.python.org/pipermail/python-dev/2003-December/041374.html


> for the correctness of "proper usage". Is this guaranteed in future 
> implementations? Especially when:
> 
>   >>> type(None) >= 0
> True

That is an interesting, but subjectively useless comparison:

>>> type(0) >= 0
True
>>> type(int) >= 0
True

When do you ever compare the type of an object with the value of another
object?



> > 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.
> > 
> Once "str.find() returns None to fail" becomes the norm then surely the 
> correct usage would be
> 
>      x = y.find(z)
>      if x is not None:
>          #...
> 
> which is still a rather ugly paradigm, but acceptable. So the transition 
> is bound to be troubling.

Perhaps, which is why I offered "x >= 0".


> > 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 .
> 
> The real problem is surely that one of find()'s legitimate return values 
> evaluates false in a Boolean context. It's especially troubling that the 
> value that does so doesn't indicate search failure. I'd prefer to live 
> with the wart until 3.0 introduces something more satisfactory, or 
> simply removes find() altogether. Otherwise the resulting code breakage 
> when the future arrives just causes unnecessary pain.

Here's a current (horrible but common) solution:

x = string.find(substring) + 1
if x:
    x -= 1
    ...


...I'm up way to late.
 - Josiah