braver wrote:
> Historically, is it possible to trace the eof-related design decision
> in stdlib?
You seem to be assuming that someone started out with a design
that included an eof() of the kind you want, and then decided
to remove it.
But I doubt that such a method was ever considered in the first
place. Someone used to programming with the C stdlib doesn't
think in terms of testing for EOF separately from reading,
because the C stdlib doesn't work that way.
Pascal started out with an eof() function because the earliest
implementations only worked with disk files. Later, when people
tried to make Pascal programs work interactively, they found
out that it was a mistake, as it provides opportunities such
as the following classic wrong way to read interactive input
in Pascal:
while not eof(input) do begin
write('Enter some data: ');
readln(input, line);
end
which stops and waits for input before printing the first
prompt.
By not providing an eof() function, C -- and Python -- make
it clear that testing for eof is not a passive operation.
It's always obvious what's going on, and it's much harder to
make mistakes like the above.
> when Python was
> codified, there should gave been some decisions made.
Some decisions were made when the C stdlib was designed, and
I think they were the right ones. Python wisely followed them.
> for line lin file:
> # look at a line
> # we can tell eof occurs right here after the last line
>
No, if the line you just read ends in "\n", you don't know whether
eof has been reached until the for-loop tries to read another line.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
