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 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-22.08:50:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Regarding special cases on the reading side, I think there should be an easy way to distinguish them. The existing RawIOBase way is probably as good as any, unless you want to take the chance to invent a better API:

* EOF (pipe closed, no more data ever) should be indicated by returning b""
* Empty pipe (still open, future data possible) should be indicated by returning None

Beware that BlockingIOError is normally not raised by Python’s standard library, despite the BufferedIOBase documentation, and I think it should say that way (the implementation, that is). See Issue 13322.

Regarding handling a broken pipe condition, it would be nice to have a way of signalling that to the caller, whether via an exception or other means. For example if the subprocess is a video player which gets closed early by the end user, it would be good to know to stop wasting time and bandwidth generating and piping video the the player.
Date User Action Args
2015-03-22 08:50:40martin.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-22 08:50:40martin.pantersetmessageid: <>
2015-03-22 08:50:40martin.panterlinkissue1191964 messages
2015-03-22 08:50:39martin.pantercreate