> sys.exit(1) # Python exits with error code 1 on EPIPE

Should be 141 instead of 1. Convention is that when a program dies because of a signal, the exit code should be 128 + the signal number, in this case 13. So, 128 + 13 = 141.

Here are some examples:

  $ ( yes; >&2 echo $? ) | head -0 
  141
  $ ( ping localhost; >&2 echo $? ) | head -0 
  141
  $ ( perl -E 'say "y" while 1'; >&2 echo $? ) | head -0 
  141

In python, when using signal(SIGPIPE, SIG_DFL), you get the correct behaviour (at least regarding the exit status):

  $ ( python -c '                                                  
  import sys                                                                    
  from signal import signal, SIGPIPE, SIG_DFL     
  signal(SIGPIPE,SIG_DFL)                    
  while True: print("y");                         
  ' ; >&2 echo $? ) | head -0
  141

> Do not set SIGPIPE’s disposition to SIG_DFL in order to avoid BrokenPipeError. Doing that would cause your program to exit unexpectedly also whenever any socket connection is interrupted while your program is still writing to it.

Regarding that socket behavior, if that's the standard in other programming environments, why is it an issue from python's perspective? Doesn't seem worth eschewing standard unix conventions. I mean, it says "unexpectedly", but isn't it actually the expected behavior? Unexpected is for python to say that what's default (SIG_DFL) is unexpected.

In the exception handler, you should reset SIGPIPE disposition and reraise the signal:

   signal.signal(signal.SIGPIPE, signal.SIG_DFL)
   os.kill(os.getpid(), signal.SIGPIPE)

(Then there's no need to fiddle with stderr.)

It also gives rationale. The rationale is ... unconvincing.

head is just an example, if you pipe rm -vfr (or any program that does more than just output) into _anything_ the reasonable and default behavior should be to run rm to completion. (And from a programmer's POV, the reasonably thing is for syscalls to handle errors by returning an error, the way every other error is handled.)

"rm -v" does.

Yep, I follow your logic. As you say, in other languages it "requires no extra work", it's more a matter of convenience.

Python in no way stops you from a having a typical response to SIGPIPE, it's as simple as handling the exception and doing a sys.exit(), but it doesn't "just happen". This makes the typical path a little more contrived, but I don't think having explicit handling makes it a bad citizen.

To torture my analogy, in my mind a "bad citizen" of the highway may be a car incapable of doing the minimum speed limit, whereas Python just has a manual transmission vs Perl's automatic (in this case).

I'm splitting hairs though, your point is fair. I just think your objection is a little strong for what comes down to convenience.