[docs] [issue13322] buffered read() and write() does not raise BlockingIOError
Martin Panter
report at bugs.python.org
Fri Jan 30 07:41:09 CET 2015
Martin Panter added the comment:
My experiments with buffered and unbuffered readers wrapping a non-blocking TCP socket, with no data received:
Method Buffered impl. Buffered doc. SocketIO impl. RawIOBase doc.
========= ============== =============== ============== ==============
read None BlockingIOError None None
read1 b"" [unclear]
readinto None BlockingIOError None None
readinto1 None BlockingIOError
readall None [unclear]
peek b"" [unclear]
readline b"" [unspecified] OSError [unspecified]
readlines [] [unspecified] OSError [unspecified]
__next__ StopIteration [unspecified] OSError [unspecified]
The non-blocking behaviour of BufferedReader matches the RawIOBase documentation better than its own documentation. I’m not sure which way it should be fixed. Is this a documentation bug or an implementation bug?
I propose to change the read1() and peek() methods to behave like the others (whether than be returning None or raising BlockingIOError). It would be nice to have a way to differentiate non-blocking data being unavailable from hard EOF, at least for non-interactive mode, and the added consistency would be nice.
A non-blocking BufferedReader use case: to be able to peek one byte of a HTTP response stream to see if the connection has been closed. Plain sockets support MSG_PEEK, but SSL sockets don’t, and a BufferedReader is already being used. Later when actually parsing the response, the reader is set to blocking mode.
----------
assignee: -> docs at python
components: +Documentation
nosy: +docs at python
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________
More information about the docs
mailing list