Author martin.panter
Recipients Andrew.Boettcher, ajaksu2, akira, astrand, cvrebert, ericpruitt, eryksun, giampaolo.rodola, gvanrossum, janzert, josiahcarlson, martin.panter, ooooooooo, parameter, r.david.murray, rosslagerwall, sbt, techtonik, v+python, vstinner, yselivanov
Date 2015-03-27.01:31:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427419872.06.0.828019987541.issue1191964@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, I think the special return value of None is only standard to the “io” module, which was added in Python 2.6 and 3. And even there it is inconsistent.

For what it’s worth, don’t have strong opinions on the special non-blocking and broken pipe cases, as long as they can be differentiated. So the current situation is fine by me. Just that potentially surprising differences with other APIs [e.g. read() -> b"" means empty buffer, not closed pipe] need documenting.

The asyncio.StreamReader.read() etc methods are documented as coroutines, so the problem of differentiating an empty buffer from a closed pipe does not exist there.

Just a thought: would it make sense for these methods to be decoupled from the subprocess class, and generalized to apply to any pipes, as a kind of Windows vs POSIX abstraction layer? Then you wouldn’t have to add duplicate methods like read_stderr_available() and read_stderr_exactly() all the time. You might also have a more portable way of doing non-blocking reads from sys.stdin, etc as well.
History
Date User Action Args
2015-03-27 01:31:12martin.pantersetrecipients: + martin.panter, gvanrossum, josiahcarlson, astrand, parameter, vstinner, techtonik, giampaolo.rodola, ajaksu2, ooooooooo, v+python, r.david.murray, cvrebert, ericpruitt, akira, Andrew.Boettcher, rosslagerwall, sbt, janzert, yselivanov, eryksun
2015-03-27 01:31:12martin.pantersetmessageid: <1427419872.06.0.828019987541.issue1191964@psf.upfronthosting.co.za>
2015-03-27 01:31:11martin.panterlinkissue1191964 messages
2015-03-27 01:31:10martin.pantercreate