feof status (was: Re: [Python-Dev] Rehabilitating fgets)

[Tim Peters]

[Eric S. Raymond]
> ...
> For some work I'm doing right now, it would be very useful if
> there were a way to query the end-of-file status of a file
> descriptor without actually doing a read.
>
> I don't see this ability anywhere in the 2.0 API.

When someone says "API", I think "C API".  In that case you can use
feof(stream) directly, or whatever the heck your platform supports for
handles (_eof(handle) on Windows, which I know is an OS you're secretly
longing to master <wink>).

I don't believe there's a way to find out from Python short of trying to
read, though.  Well, I suppose you could try to compare f.tell() to the
size, if you knew that f.tell() and "the size" made sense for f ...

> 1. Am I missing something obvious?

I don't know!  I never asked Guido about this, and given that he's not on
vacation now I'm not allowed to channel him.  I would hazard a guess,
though, that he thinks "you do or don't get something back when you read" is
clearer than "you may or may not get something back when you read,
regardless of which answer I give you in response to .eof() -- depending".
The latter is particularly muddy in a threaded environment, even for plain
old disk files.

> 2. If the answer to 1 is that I am not, in fact, being a dumbass,
>    what is the right way to support this?  The obvious alternatives
>    are an eof member (analogous to the existing `closed' member, or
>    an eof() method.  I favor the latter.
>
> 3. If we agree on a design, I'm willing to implement this at least
>    for Unix.  Should be a small project.

I agree an .eof() method would be better than a data member.  Note that
whenever Python internals hit stream EOF today, they call clearerr(), so
simply adding an feof() wrapper wouldn't suffice.  Guido seemed to try to
make sure that feof() would never be useful <0.8 wink>.

one-of-life's-little-mysteries-ly y'rs  - tim