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

[Cameron Simpson]

On 14Jun2009 12:33, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Antoine Pitrou wrote:
>> The original docstring for peek() says:
>>
>>         ...we
>>         do at most one raw read to satisfy it.
>>
>> In that light, I'm not sure it's a bug
>
> It may be behaving according to the docs, but is that
> behaviour useful?
>
> Seems to me that if you're asking for n bytes, then it's
> because you're doing some kind of parsing that requires
> lookahead, and nothing less than n bytes will do.
>
> I think it would be more useful if the "at most one
> raw read" part were dropped. That would give it the
> kind of deterministic behaviour generally expected
> when dealing with buffered streams.

Is it possible to access the buffer? I see nothing in the docs.

People seem to want peek() to be "read() without moving the read
offset", which it almost seems to be. Nick and Greg both want it to
really be that, and thus do enough raw reads to get "n" bytes; Nick
wants a peek1() like read1(), too.

It has a pleasing feel to me, too. But ...

For myself, I'd expect more often to want to see if there's stuff in the
buffer _without_ doing any raw reads at all. A peek0(n), if you will:

  Read and return up to n bytes without calling on the raw stream.

It feels like peek is trying to span both extremes and doesn't satisfy
either really well.

If peek gets enhanced to act like read in terms of the amount of data
returned, should there not be a facility to examine buffered data
without raw reads?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Being on a Beemer and not having a wave returned by a Sportster is like
having a clipper ship's hailing not returned by an orphaned New Jersey
solid waste barge.   - OTL