Cameron Simpson wrote:
> On 16Jun2009 02:18, MRAB <python at mrabarnett.plus.com> wrote:
>>> 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.
>
> Am I missing something?
>
> In the face of an _empty_ buffer (which I can't tell from outside) how
> do I prevent peek() blocking? More generally, if I go peek(n) and if n >
> bytes_in_buffer_right_now and the raw stream would block if a raw read
> is done?
>
> My concerns would go away if I could probe the buffer content size;
> then I could ensure peek(n) chose n <= the content size. If that's not
> enough, my problem - I can choose to read-and-block or go away and come
> back later.
I was thinking along the lines of:
def peek(self, size=None, block=True)
If 'block' is True then return 'size' bytes, unless the end of the
file/stream is reached; if 'block' is False then return up to 'size'
bytes, without blocking. The blocking form might impose a limit to how
much can be peeked (the maximum size of the buffer), or it might enlarge
the buffer as necessary.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4