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

[Nick Coghlan]

Cameron Simpson wrote:
> On 13Jun2009 12:24, Nick Coghlan <ncoghlan at gmail.com> wrote:
> | I would phrase this suggestion as users having a reasonable expectation
> | that the following invariant should hold for a buffered stream:
> | 
> |   f.peek(n) == f.read(n)
> | 
> | Since the latter method will perform as many reads of the underlying
> | stream as necessary to reach the requested number of bytes (or EOF),
> | then so should the former.
> 
> I disagree. If that were that case, why have peek() at all? I realise
> that it doesn't move the logical position, but it does mean that
> peek(huge_number) imposes a requirement to grow the stream buffer
> arbitrarily.
> 
> A peek that does at most one raw read has the advantage that it can pick up
> data outside the buffer but lurking in the OS buffer, yet to be obtained.
> Those data are free, if they're present. (Of course, if they're absent
> peek() wil still block).

Note my suggestion later that if the above invariant were to be adopted
then a peek1() method should be added to parallel read1().

However, from what Benjamin has said, a more likely invariant is going
to be:

  preview = f.peek(n)
  f.read(n).startswith(preview)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------