Movatterモバイル変換
[0]ホーム
[Python-Dev] Remove str.find in 3.0?
Guido van Rossumgvanrossum at gmail.com
Fri Aug 26 22:10:00 CEST 2005
On 8/26/05, Terry Reedy <tjreedy at udel.edu> wrote:> Can str.find be listed in PEP 3000 (under builtins) for removal?Yes please. (Except it's not technically a builtin but a string method.)> Would anyone really object?Not me.> Reasons:>> 1. Str.find is essentially redundant with str.index. The only difference> is that str.index Pythonically indicates 'not found' by raising an> exception while str.find does the same by anomalously returning -1. As> best as I can remember, this is common for Unix system calls but unique> among Python builtin functions. Learning and remembering both is a> nuisance.>> 2. As is being discussed in a current c.l.p thread, -1 is a legal indexing> subscript. If one uses the return value as a subscript without checking,> the bug is not caught. None would be a better return value should find not> be deleted.>> 3. Anyone who prefers to test return values instead of catch exceptions can> write (simplified, without start,end params):>> def sfind(string, target):> try:> return string.index(target)> except ValueError:> return None # or -1 for back compatibility, but None better>> This can of course be done for any function/method that indicates input> errors with exceptions instead of a special return value. I see no reason> other than history that this particular method should be doubled.I'd like to add:4. The no. 1 use case for str.find() used to be testing whether asubstring was present or not; "if s.find(sub) >= 0" can now be writtenas "if sub in s". This avoids the nasty bug in "if s.find(sub)".> If .find is scheduled for the dustbin of history, I would be willing to> suggest doc and docstring changes. (str.index.__doc__ currently refers to> str.find.__doc__. This should be reversed.)-- --Guido van Rossum (home page:http://www.python.org/~guido/)
More information about the Python-Devmailing list
[8]ページ先頭