Movatterモバイル変換
[0]ホーム
[Python-Dev] Remove str.find in 3.0?
Guido van Rossumgvanrossum at gmail.com
Sun Aug 28 00:54:41 CEST 2005
On 8/27/05, Josiah Carlson <jcarlson at uci.edu> wrote:> With the existance of literally thousands of uses of .find and .rfind in> the wild, any removal consideration should be weighed heavily - which> honestly doesn't seem to be the case here with the ~15 minute reply time> yesterday (just my observation and opinion). If you had been ruminating> over this previously, great, but that did not seem clear to me in your> original reply to Terry Reedy.I hadn't been ruminating about deleting it previously, but I was wellaware of the likelihood of writing buggy tests for find()'s returnvalue. I believe that str.find() is not just something that can beused to write buggy code, but something that *causes* bugs over andover again. (However, see below.)The argument that there are thousands of usages in the wild doesn'tcarry much weight when we're talking about Python 3.0.There are at least a similar number of modules that expectdict.keys(), zip() and range() to return lists, or that depend on thedistinction between Unicode strings and 8-bit strings, or on bareexcept:, on any other feature that is slated for deletion in Python3.0 for which the replacement requires careful rethinking of the coderather than a mechanical translation.The *premise* of Python 3.0 is that it drops backwards compatibilityin order to make the language better in the long term. Surely youbelieve that the majority of all Python programs have yet to bewritten?The only argument in this thread in favor of find() that made sense tome was Tim Peters' observation that the requirement to use atry/except clause leads to another kind of sloppy code. It's hard tojudge which is worse -- the buggy find() calls or the buggy/cumbersometry/except code.Note that all code (unless it needs to be backwards compatible toPython 2.2 and before) which is using find() to merely detect whethera given substring is present should be using 's1 in s2' instead.Another observation: despite the derogatory remarks about regularexpressions, they have one thing going for them: they provide a higherlevel of abstraction for string parsing, which this is all about.(They are higher level in that you don't have to be countingcharacters, which is about the lowest-level activity in programming --only counting bytes is lower!)Maybe if we had a *good* way of specifying string parsing we wouldn'tbe needing to call find() or index() so much at all! (A good exampleis the code that Raymond lifted from ConfigParser: a semicolonpreceded by whitespace starts a comment, other semicolons don't.Surely there ought to be a better way to write that.)All in all, I'm still happy to see find() go in Python 3.0, but I'mleaving the door ajar: if you read this post carefully, you'll knowwhat arguments can be used to persuade me.-- --Guido van Rossum (home page:http://www.python.org/~guido/)
More information about the Python-Devmailing list
[8]ページ先頭