Author martin.panter
Recipients anacrolix, benjamin.peterson, docs@python, martin.panter, neologix, petri.lehtinen, pitrou, python-dev, sbt, stutzbach
Date 2015-01-30.06:41:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1422600069.59.0.617808361974.issue13322@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-01-30 06:41:09martin.pantersetrecipients: + martin.panter, pitrou, benjamin.peterson, stutzbach, anacrolix, neologix, docs@python, python-dev, sbt, petri.lehtinen
2015-01-30 06:41:09martin.pantersetmessageid: <1422600069.59.0.617808361974.issue13322@psf.upfronthosting.co.za>
2015-01-30 06:41:09martin.panterlinkissue13322 messages
2015-01-30 06:41:08martin.pantercreate