akira added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1191964> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
