[Python-Dev] Remove str.find in 3.0?
jcarlson at uci.edu
Sun Aug 28 12:50:17 CEST 2005
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
> >>> None >= 0
Please see this previous post on None comparisons and why it is unlikely
> for the correctness of "proper usage". Is this guaranteed in future
> implementations? Especially when:
> >>> type(None) >= 0
That is an interesting, but subjectively useless comparison:
>>> type(0) >= 0
>>> type(int) >= 0
When do you ever compare the type of an object with the value of another
> > 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
x -= 1
...I'm up way to late.
More information about the Python-Dev