Python & EPIPE: Handling Chg Proposal

[Randall Hopper]

Donn Cave:
 |Quoth Randall Hopper <aa8vb at yahoo.com>:
 ||      The gist of the problem is that any program which writes to stdout or
 || stderr really needs to handle EPIPE to avoid tripping python error
 || tracebacks, and doing so is non-trivial and obfuscates otherwise-simple
 || Python code.
 ||
 || Basically, this is buggy Python code:
 ||     python -c "for i in xrange(100000): print 'Lots of output'" | head
 |
 || PROPOSAL:
 ||
 ||     Add an "epipe_error" attribute to the file object.  It would determine
 ||     whether EPIPE errors from read()/write() calls generate SystemExit
 ||     or IOError exceptions.
 ||
 || By default EPIPEs received from the stdin/out/err files would generate
 || SystemExit exceptions (epipe_error = 0).  All other files would default to
 || IOError exceptions (epipe_error = 1).
 |
 |Is the problem really the exception, or the traceback?  It looks to me
 |like it's the traceback, and nothing else about the exception is any
 |problem for you.

It's termination with an error message.  

Exception and traceback neither are problems; both SystemExit and IOError
generate exceptions and invoke stack tracebacks after all.


 |What if the top level handler that prints out these tracebacks just
 |handled this one silently, as it does with SystemExit?  That would
 |allow programs to catch pipe errors if they want, a job that could
 |be much more awkward if some pipe errors raise SystemExit instead.

That's one of the options I considered (see the "Possible Solutions"
comments at the bottom of my broken_pipe.py script).  However, if you get
EPIPE from a program-created socket and don't handle it, chances are you
want to know about it.  It's only the standard pipes set up by the system
that you don't want to see errors for.

The method I proposed seemed to be flexible, providing reasonable defaults,
but allowing the user to reconfigure the default behavior on a per-file basis.

-- 
Randall Hopper
aa8vb at yahoo.com