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

[MRAB]

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.