On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> 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 if the API changed to raise EOFError exceptions. It's not a coincidence that raw_input() raises EOFError but readline() doesn't -- the readline API was designed after externsive experience with raw_input(). The situation is different than for find(): - there aren't two APIs that only differ in their handling of the exceptional 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 as non-error return values works just fine (as long as you have another way to test for termination) Also, even if read() raised EOFError instead of returning '', code that expects certain data wouldn't be simplified -- after attempting to read e.g. 4 bytes, you'd still have to check that you got exactly 4, so there'd be three cases to handle (EOFError, short, good) instead of two (short, good). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
