On 12/6/2010 4:23 PM, Steven D'Aprano wrote:
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
It's really unfortunate, though, that Python 3 didn't offer a way to
peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite the obvious flaws
in the idea.
There's no general way of telling whether or not a lazy sequence is done
except to actually generate the next value, and caching that value is not
appropriate for all such sequences since it could depend on factors which
have changed between the call to peek and the call to next.
Right.
Pascal had the predicates "eoln(file)" and "eof(file)", which
were tests for end of line and end of file made before reading. This
caused much grief with interactive input, because the test would
stall waiting for the user to type something. Wirth originally
intended Pascal for batch jobs, and his version didn't translate
well to interactive use. (Wirth fell in love with his original
recursive-descent compiler, which was simple but limited. He
hated to have language features that didn't fit his compiler model
well. This held the language back and eventually killed it.)
C I/O returned a unique value on EOF, but there was no way to
test for it before reading. Works much better. The same issues apply
to pipes, sockets, qeueues, interprocess communication, etc.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
