[Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Jun 17 00:55:26 CEST 2009


Cameron Simpson wrote:
> I normally avoid
> non-blocking requirements by using threads, so that the thread gathering
> from the stream can block.

If you have a thread dedicated to reading from that
stream, then I don't see why you need to peek into
the buffer. Just have it loop reading a packet at a
time and put each completed packet in the queue.
If several packets arrive at once, it'll loop around
that many times before blocking.

> arguably read1() is a lousy name too, on the same basis.

Certainly.

> My itch is that peek() _feels_ like it should be "look into the buffer"
> but actually can block and/or change the buffer.

My problem with the idea of looking into the buffer
is that it crosses levels of abstraction. A buffered
stream is supposed to behave the same way as a
deterministic non-buffered stream, with the buffer
being an internal optimisation detail that doesn't
exist as far as the outside world is concerned.

Sometimes it's pragmatic to break the abstraction,
but it should be made very obvious when you're doing
that. So I'd prefer something like peek_buffer() to
make it perfectly clear what's being done.

Anything else such as peek() that doesn't explicitly
mention the buffer should fit into the abstraction
properly.

-- 
Greg


More information about the Python-Dev mailing list