Steve Holden <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > Donovan Baarda <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com