Why does CPython raise BrokenPipeError instead of dying on SIGPIPE like a C filter?

## The default the interpreter overrides On Unix, `SIGPIPE` (signal number 13) has a default disposition of *terminate*. When a process writes into a pipe or socket with no reader left, the kernel first raises `SIGPIPE` against the writer; if the signal is at its default, the process dies on the spot. This is exactly why classic Unix filters compose so cleanly: a producer feeding a reader that exits early is simply killed, printing nothing, and the shell reports exit status 141 — 128 plus the signal number. CPython does not want that. During interpreter startup it installs `signal.SIG_IGN` as the disposition for `SIGPIPE`. Ignoring the signal changes what the kernel does with the failed write: instead of killing the process it returns `-1` with errno set to `EPIPE`. The I/O layer sees that errno and raises `BrokenPipeError`. You can see the disposition for yourself before touching anything, with `signal.getsignal(signal.SIGPIPE)`. ## Why the interpreter makes that choice Death by signal is uncooperative. It unwinds nothing. A process killed by `SIGPIPE` runs no `finally` blocks, exits no context managers, flushes no other open file, and never reaches `atexit` handlers. For a 20-line C filter that owns no state that is fine. For a general-purpose language whose programs hold database transactions, temporary files, locks and half-written output files, silently vanishing mid-write is an unacceptable default. Turning the condition into an ordinary exception lets normal Python cleanup run and lets the program decide whether a vanished reader is fatal. There is a second reason. `EPIPE` also reaches code that has nothing to do with a shell pipeline — every socket write to a departed peer produces it. A server that died on signal every time a client disconnected would be unusable, so the exception model is the only workable one for the network case, and the interpreter applies one consistent policy. ## What it costs The cost is the one everybody meets first: a Python program in a pipeline is noisy where a Unix tool is quiet. Piping a long-running producer into a reader that takes only the first line prints a traceback ending in `BrokenPipeError: [Errno 32] Broken pipe`, and frequently a second complaint from the interpreter's own flush of stdout as it shuts down. Nothing is broken; the program is reporting an error condition that the Unix convention would have swallowed. ## The disposition is not a Python-level handler `SIG_IGN` is set at the operating-system level, not registered as a Python callable. That distinction matters. A Python signal handler installed with `signal.signal` merely sets a flag in C and runs your function later, between bytecodes, always on the main thread of the main interpreter. Ignoring is different: the kernel never delivers anything, so there is no main-thread constraint and no deferred callback. A write failing in a worker thread raises `BrokenPipeError` right there, in that thread, from the call that failed. ## Inheritance across exec Signal dispositions survive `exec`, and an *ignored* signal stays ignored in the new program image. If Python simply handed its process image to a child, every Unix tool it launched would inherit an ignored `SIGPIPE` and start misbehaving in pipelines. `subprocess.Popen` guards against this: by default it restores signals that Python set to `SIG_IGN` back to `SIG_DFL` in the child, just before exec. That default is worth knowing — turning it off is how a spawned tool ends up mysteriously surviving, and complaining about, a broken pipe it should have died on. ## Portability Windows has no `SIGPIPE`; the constant does not exist in the `signal` module there, so code that touches it must be guarded. The failure itself still surfaces: a write to a closed Windows pipe returns an error code that CPython maps onto the same `BrokenPipeError`. That is a useful property — you can write portable handling around the exception, while any code that manipulates the *signal* is Unix-only by nature.