It seems this can be triggered easily with echo, since that appears to reliably close stdin on startup (Discovered via http://stackoverflow.com/questions/16314321).

Compare (using a recent trunk build, although I see the same behaviour with the system 3.3 installation):

$ ../py3k/python -c 'print("Hello world!")' | echo

Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

$ ../py3k/python -c 'print("Hello world!")' | xargs echo
Hello world!

$ ../py3k/python -c 'print("Hello world!")' | cat
Hello world!

Given that flush/close related exceptions are automatically ignored in destructors, something else must be going on here.

It turns out that the *explicit* flush calls during interpreter finalization use PyErr_WriteUnraisable on failure to flush stdout instead of silently ignoring the exceptions (http://hg.python.org/cpython/file/ed011b0d7daf/Python/pythonrun.c#l457).

This is reasonable, since a broken pipeline *is* an error that the user may need to do something about (e.g. as with echo, they next pipeline stage may not being invoked correctly, thus breaking the pipe)

However, in the specific case of a broken pipe, I believe it is desirable for us to write out a cleaner message than the generic PyErr_WriteUnraisable output.