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@python components: +Documentation nosy: +docs@python _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13322> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
