Greg Ewing wrote:
That's exactly why I think the blocking version should
keep reading until the requested number of bytes is
available (or the buffer is full or EOF occurs).
Do you mean that the blocking version should keep waiting for new bytes
until they show up?
This would not be acceptable,
Greg Ewing wrote:
Even if you don't mention it explicitly, its
existence shows through in the fact that there
is an arbitrary limit on the amount you can
peek ahead, and that limit needs to be documented
so that people can write correct programs.
This is true of both kinds of peeking, so I
conce
MRAB wrote:
I was thinking along the lines of:
def peek(self, size=None, block=True)
I think this is fine too. :)
If 'block' is True then return 'size' bytes, unless the end of the
file/stream is reached; if 'block' is False then return up to 'size'
bytes, without blocking. The blocking
Cameron Simpson wrote:
Indeed, though arguably read1() is a lousy name too, on the same basis.
My itch is that peek() _feels_ like it should be "look into the buffer"
but actually can block and/or change the buffer.
I guess all the buffer operations should be transparent to the user if
he wan
