homepage

It is common to have an inflexible C wrapper with lots of undesired output. However it is not so trivial to supress (or redirect) that output from Python in a selective way. contextlib.redirect_stdout doesn't help, since it only changes sys.sdout, without touching the actual file descriptor. The following worked for my use case, which I adapted from here http://eli.thegreenplace.net/2015/redirecting-all-kinds-of-stdout-in-python/:
import sys
import os
from contextlib import contextmanager, redirect_stdout
@contextmanager
def supress_stdout():
 devnull = open(os.devnull, 'wb')
 try:
 stdout_flieno = sys.stdout.fileno()
 except ValueError:
 redirect = False
 else:
 redirect = True
 sys.stdout.flush()
 #sys.stdout.close()
 devnull_fileno = devnull.fileno()
 saved_stdout_fd = os.dup(stdout_flieno)
 os.dup2(devnull_fileno, stdout_flieno)
 with redirect_stdout(devnull):
 yield
 if redirect:
 os.dup2(stdout_flieno, saved_stdout_fd)

This was discussed in the original redirect_stdout issue (issue 15805). It was suggested then that C level redirection was a separate issue, and should probably be something in the subprocess module.

Well, the simple minded example I posted has so many bugs (many of which I don't understand, for example why it destroys the stdout of an interpreter permanently) that I really think this feature is necessary.

Is it really common to have a C wrapper with undesirable output? I suspect there is not much demand for this feature. Maybe this would be better outside of Python’s standard library.

Considering Python is used often to interact with lower level
languages, it seems interesting to have the ability to control the
"real" standard output and error that those languages use. Note that
redirecting to /dev/null is only one possible application of this
feature. Others would be for example linking the stout to the logging
module.
Specifically regarding redirecting to /dev/null, in my experience this
would be fairly useful In scientific software where low level code
tends to be used on scientific merits rather than on how much control
it has over verbosity.
On Sun, May 8, 2016 at 12:04 AM, Martin Panter <report@bugs.python.org> wrote:
>
> Martin Panter added the comment:
>
> Is it really common to have a C wrapper with undesirable output? I suspect there is not much demand for this feature. Maybe this would be better outside of Python’s standard library.
>
> ----------
> nosy: +martin.panter
> status: open -> languishing
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue24500>
> _______________________________________