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

[Greg Ewing]

Cameron Simpson wrote:

> But people not using threads, or at any rate not
> dedicating a thread to the reading task, don't have such luxury.

But without a dedicated thread you need to use
select() or poll(), and then buffering causes other
headaches.

> Are we disputing the utility of being able to ask "how much might I
> read/peek without blocking"?

I'm saying that I don't see how I would make use
of such a thing, so I probably wouldn't mind if
it didn't exist.

> Or disputing the purpose of peek, which
> feels to me like it should/might ask that question, but doesn't.

I think what I'm saying is that there are two
distinct use cases being talked about for a peek-like
operation, and different people seem to have different
ideas on which one should be mapped to the name "peek".
So perhaps they should both be given more-explicit
names.

> It's perfectly possible, even reasonable, to avoid talking about the
> buffer at all. I'd be happy not to mention the buffer.

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
concede that they both break the abstraction.

However I think the non-blocking peek breaks it
more than the blocking one, because it also
brings non-deterministic behaviour.

-- 
Greg