This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Jeremy.Fishman, ncoghlan, pitrou, terry.reedy, ulidtko
Date 2013-09-23.07:53:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
It seems this can be triggered easily with echo, since that appears to reliably close stdin on startup (Discovered via

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 (

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.
Date User Action Args
2013-09-23 07:53:49ncoghlansetrecipients: + ncoghlan, terry.reedy, pitrou, ulidtko, Jeremy.Fishman
2013-09-23 07:53:49ncoghlansetmessageid: <>
2013-09-23 07:53:49ncoghlanlinkissue11380 messages
2013-09-23 07:53:49ncoghlancreate