This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients amaury.forgeotdarc, beazley, dabeaz, flox, gregory.p.smith, loewis, martin.panter, ned.deily, pitrou, r.david.murray, rosslagerwall, roysmith
Date 2015-10-27.11:52:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445946765.94.0.767454315222.issue7322@psf.upfronthosting.co.za>
In-reply-to
Content
IMO it might make sense in some cases to disallow subsequent reading from a buffered socket reader (or probably any BufferedReader) that raises an exception (not just a timeout). But the restriction seems unnecessary for unbuffered raw readers, and it also seems to go against the “consenting adults” philosophy for David Murray’s test server case.

David Beazley: For non-blocking sockets, the documentation currently says “the socket must be in blocking mode”. I’m not sure why that restriction is necessary; maybe it could be lifted at least for raw unbuffered streams.

Maybe you could make an argument for caching the partial data in the BufferedReader if a timeout (or no more non-blocking data, or other exception) occurs. The biggest problem is that it could mean storing more than the normal buffer size. I would think this would be a new feature (for 3.6+) rather than a behavioural bug fix though.

And see also Issue 13322 about inconsistencies with buffered reading non-blocking streams in general.
History
Date User Action Args
2015-10-27 11:52:46martin.pantersetrecipients: + martin.panter, loewis, beazley, gregory.p.smith, amaury.forgeotdarc, roysmith, pitrou, ned.deily, r.david.murray, flox, dabeaz, rosslagerwall
2015-10-27 11:52:45martin.pantersetmessageid: <1445946765.94.0.767454315222.issue7322@psf.upfronthosting.co.za>
2015-10-27 11:52:45martin.panterlinkissue7322 messages
2015-10-27 11:52:45martin.pantercreate