Cameron Simpson wrote: > On 13Jun2009 12:24, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
