On Sat, Jun 30, 2018 at 9:02 PM Alfred Perlstein <alf...@freebsd.org> wrote:
> > > On 6/30/18 4:20 PM, Greg Ewing wrote: > > Alfred Perlstein wrote: > >> I am asking if there's a way we can discourage the use of > >> "signal(SIGPIPE, SIG_DFL)" unless the user really understands what > >> they are doing. > > > > Maybe there's some way that SIGPIPEs on stdout could be handled > > differently by default, so that they exit silently instead of > > producing an ugly message. That would remove the source of pain > > that's leading people to do this. > > > Thank you Greg, I can poke around into this, it would be a bit of a > challenge as the descriptor which causes BrokenPipeError does not appear > to be stored within the exception so differentiating it from other > exceptions might be a bit tricky. > > I will look into this in the coming weeks. Any tips on accomplishing > this? I was thinking of encoding the fd responsible for causing the > error into the exception somehow and then checking to see if it was > stdout, then not reporting on it. > There's PyErr_SetFromErrnoWithFilenameObject(), which generates an OSError with a filename. We could have a similar call PyErr_SetFromErrnoWithFileDescriptor(), which generates an OSError (or a subclass like BrokenPipeError) with a file descriptor. Just pick a new attribute name to store the fd on, e.g. file_descriptor (I guess it would default to None). Then of course you will have to write the code that calls this instead of plain PyErr_SetFromErrno() for those syscalls where a file descriptor is present. And when Python exits with a BrokenPipeError it could suppress printing the stack trace when the file_descriptor field equals 1. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
