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

[Steve Holden]

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

for the correctness of "proper usage". Is this guaranteed in future 
implementations? Especially when:

  >>> type(None) >= 0
True

> 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.

> 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.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/