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 akira
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 2014-06-03.02:44:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1401763442.34.0.513012480503.issue1191964@psf.upfronthosting.co.za>
In-reply-to
Content
> First, with the use of Overlapped IO on Windows, BlockingIOError should never come up, and we don't even handle that exception.

Is it correct that the way to distinguish between "would block" and EOF 
is Popen.poll()? Is it possible to detect it in _nonblocking() methods
 and raise BlockingIOError manually (or return None for read_..()) in "would block" case?

> But the majority of consumers of this API (and most APIs in general) will experience failure and could lose critical information before they realize, "Oh wait, I need to wrap all of these communication pieces in exception handlers."

It is an argument to catch *all* OSErrors internally that is not a good idea.

Popen.communicate() hides EPIPE in the current implementation therefore its behaviour 
shouldn't change. But subprocess' code allows Popen.stdin.write() to raise "broken pipe".
My questions are about _nonblocking() methods e.g., it is not obvious whether 
write_nonblocking() should mask EPIPE as EOF. If it does then It should be documented.
History
Date User Action Args
2014-06-03 02:44:02akirasetrecipients: + akira, gvanrossum, josiahcarlson, astrand, parameter, vstinner, techtonik, giampaolo.rodola, ajaksu2, ooooooooo, v+python, r.david.murray, cvrebert, ericpruitt, Andrew.Boettcher, rosslagerwall, sbt, martin.panter, janzert, yselivanov, eryksun
2014-06-03 02:44:02akirasetmessageid: <1401763442.34.0.513012480503.issue1191964@psf.upfronthosting.co.za>
2014-06-03 02:44:02akiralinkissue1191964 messages
2014-06-03 02:44:00akiracreate