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

MRAB python at mrabarnett.plus.com
Tue Jun 16 03🔞22 CEST 2009

Cameron Simpson wrote:

On 16Jun2009 11:21, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

Cameron Simpson wrote:

It seems like whenever I want to do some kind of opportunistic but non-blocking stuff with a remote service Do you actually do this with buffered streams? Sure, in C, python and perl quite happily. In some circumstances. Provided you're careful about when to fflush() it can all go quite smoothly. It's certainly not applicable to everything. I find it's better to steer well clear of buffered I/O objects when doing non-blocking stuff, because they don't play well with other things like select(). Ah, the non-blockingness. Well that's the rub. I normally avoid non-blocking requirements by using threads, so that the thread gathering from the stream can block. Then the consumer can poll a Queue from the worker thread, etc. I really don't like select(/poll/epoll etc) much; aside from select's scaling issues with lots of files (hence poll/epoll) there are high performance things where having an event loop using select is a good way to go, but I generally prefer using threads and/or generators to make the code clear (single flow of control, single task for the block of code, etc) if there's no reason not to. Anyhow, I wouldn't be opposed to having a way of looking into the buffer, but it should be a separate API -- preferably with a better name than peek0(), which gives no clue at all about what it does differently from peek(). 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. Can block, but not if you don't want it too. You might just want to see what, if anything, is currently available, up to n bytes.

More information about the Python-Dev mailing list