Movatterモバイル変換
[0]ホーム
[Python-Dev] Remove str.find in 3.0?
Josiah Carlsonjcarlson 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> behavior>> >>> None >= 0> FalsePlease see this previous post on None comparisons and why it is unlikelyto 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> TrueThat is an interesting, but subjectively useless comparison:>>> type(0) >= 0True>>> type(int) >= 0TrueWhen do you ever compare the type of an object with the value of anotherobject?> > 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) + 1if x: x -= 1 ......I'm up way to late. - Josiah
More information about the Python-Devmailing list
[8]ページ先頭