So, there are two possible approaches to this issue:
1) Just take the upstream patch and backport it to Python 2.7
2) Use diff between Python 2.7 subprocess.py and subprocess32.py from python-subprocess32.

The first approach is easy, but error-prone. Upstream may have (and they probably did) eventually changed some lines added in this patch - there were either some problems or some improvements were needed. This means that the second approach is better - but python-subprocess32 also has lots of other backported features that, if included in patch for this bug, may break backwards compatibility. So the way we'll proceed here is that we'll do a diff between Python 2.7 subprocess.py and subprocess32.py and keep just the changes that are related to this bug. This will not be easy and we need to make sure it will work, but I think we can do this. I'll add dev_ack+ when we're sure we have the right patch.

We've decided to not reset the signal handler by default. You can have the handler be reset by calling Popen with restore_sigpipe keyword argument set to True.

Can you detail _why_ you decided not to set the default for restore_sigpipe to True? I've just hit this issue again (and again a weird failure mode with a program stuck in an infinite loop). Please reconsider the importance of this.

Can anyone think of a use case were people may be relying on getting EPIPE rather than SIGPIPE? Surely if they're relying on that weird behavior they're not relying on python to have set the non standard signal handling, and would do it within the sub process. I explained already in bug #859169 why not having restore_sigpipe=False as the default is next to useless as there are already easy (and more standard) workarounds to apply.

In Python 3, the reset is implemented in C code. The backport to Python 2 was done in Python code, which needs to call signal.signal.
But, mod_wsgi with WSGIRestrictSignal replaces signal.signal, so the backport fails in that scenario This is a serious regression for FreeIPA (see bug #1257613).

Adding a restore_sigpipe argument caused breakage in, for example, Gluster (see bug #1267848).

Yes I agree the restore_sigpipe argument is problematic and not really useful.

As for generally resetting SIGPIPE I see WSGIRestrictSignal is used for a few reasons including:

"Apache will ensure that the signal SIGPIPE is set to SIG_IGN. If a WSGI application needs to override this, it must ensure that it is reset to SIG_IGN before any Apache code is run. In a multi threaded MPM this would be practically impossible to ensure so it is preferable that the handler for SIG_PIPE also not be changed."

It's a pity python/apache don't set a default empty handler for SIGPIPE,
as that would auto revert to standard handling upon exec().

I suppose we could handle most cases by doing this unconditionally in subprocess.py.

  self.pid = os.fork()
  if self.pid == 0:
    try:
      signal.signal(signal.SIGPIPE, signal.SIG_DFL)
    except:
      pass # maybe warn

thanks for the info

The current behavior is not ideal, but the fix introduces regressions, and a workaround is available for software that needs the reset functionality.
Therefore, I unfortunately need to close this as WONTFIX.