[Python-Dev] Remove str.find in 3.0?

[Guido van Rossum]

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 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/)