Movatterモバイル変換
[0]ホーム
[Python-Dev] Remove str.find in 3.0?
Guido van Rossumgvanrossum at gmail.com
Sat Aug 27 16:29:07 CEST 2005
On 8/27/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:> [Martin]> > For another example, file.read() returns an empty string at EOF.>> When my turn comes for making 3.0 proposals, I'm going to recommend> nixing the "empty string at EOF" API. That is a carry-over from C that> made some sense before there were iterators. Now, we have the option of> introducing much cleaner iterator versions of these methods that use> compact, fast, and readable for-loops instead of multi-statement> while-loop boilerplate.-1.For reading lines we already have that in the status quo.For reading bytes, I *know* that a lot of code would become uglier ifthe API changed to raise EOFError exceptions. It's not a coincidencethat raw_input() raises EOFError but readline() doesn't -- thereadline API was designed after externsive experience withraw_input().The situation is different than for find():- there aren't two APIs that only differ in their handling of theexceptional case- the error return value tests false and all non-error return values tests true- in many cases processing the error return value the same asnon-error return values works just fine (as long as you have anotherway to test for termination)Also, even if read() raised EOFError instead of returning '', codethat expects certain data wouldn't be simplified -- after attemptingto read e.g. 4 bytes, you'd still have to check that you got exactly4, so there'd be three cases to handle (EOFError, short, good) insteadof two (short, good).-- --Guido van Rossum (home page:http://www.python.org/~guido/)
More information about the Python-Devmailing list
[8]ページ先頭