Josiah Carlson wrote:
Donovan Baarda
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/