Martin Panter added the comment:
It seems two different issues have popped up:
## 1. Windows behaviour ##
Windows apparently doesn’t handle broken pipes consistently, sometimes raising
an EINVAL error, and sometimes not raising any error. I don’t know if this is a
problem with Python, or a quirk with Windows. (Just tried with Wine, and it
always raises ENOSPC instead, but I guess that’s a Wine-specific quirk.)
Perhaps we can change the offending test case to the following, at least until
someone can investigate and explain what is going on:
...
if mswindows:
try:
proc.__exit__(None, None, None)
except OSError: # Sometimes raises EINVAL, sometimes no error
pass
else:
self.assertRaises(BrokenPipeError, proc.__exit__, None, None, None)
...
## 2. Suppressing BrokenPipeError ##
I don’t have any strong opinions. I think in the past when writing to a
process’s input raises BrokenPipeError, I have tended to skip the writing and
go on to analyse the process’s output and/or exit status (the same as if
writing succeeded).
Some arguments for raising BrokenPipeError (current behaviour):
* No change in behaviour
* Slightly simpler implementation
* Consistent with the way stdin.close() works
* Potentially more flexible if the user cares about handling a broken pipe
specially.
* Exiting the context manager does not return any data, so no return value is
lost by raising an exception. In contrast, one of the reasons communicate() was
changed to sometimes suppress the exception is so that the captured output is
returned and not lost.
Arguments for suppressing BrokenPipeError:
* Consistent with the way communicate() is meant to work, according to Issue
10963.
* Probably more useful in normal use cases
* User can always explicitly call stdin.close() if they really want to handle
the BrokenPipeError
* Avoid possible confusion and hiding a more important exception, if one was
already raised inside the context manager, for example if a subprocess crash
was detected, or if stdin.write() already raised its own BrokenPipeError.
Replying to Victor: “the process always exit after __exit__?”:
__exit__ is meant to call wait(), so it only returns when the subprocess exits.
It could potentially still be running despite closing its input pipe. This
issue was originally about making sure __exit__ called wait() in all cases.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
