Cristian Consonni added the comment:

Hi David,

*now* I understand your point (!) and, yes, this is something I have thought 
about.

Basically, I was thinking that with this addition I wanted an easy way to 
suppress stdout/stderr output. I have thought about simply exposing 
subprocess.Popen's stderr and stdout parameters (i.e. passing stdout and stdout 
to subprocess.Popen as they are) but this would have meant that to suppress the 
output one should do the following:

```
import webbrowser
import subprocess

webbrowser.open('http://www.example.com', stdout=subprocess.DEVNULL, 
stderr=subprocess.DEVNULL)
```

This seems to be utterly complicated to me, also I don't like to have to import 
the subprocess module just to make use of subprocess.DEVNULL. (an alternative 
would be passing file(os.devnull, "r+") à la Python 2.7, but the problem of 
needing an additional module remains). 
Also, I find that *in the context of the webbrowser module* using 
subprocess.Popen semantics i.e.:
```
webbrowser.open('http://www.example.com', stdout=None, stderr=None)
```
to mean that the stderr and stdout file descriptors are inherited from the 
parent process is quite counter-intuitive.

That's why I have changed the semantics of the parameters the way I did.

A couple of possible alternatives were changing the name of the parameters:
1) suppress_stdout/suppress_stderr. In this case True (which is not a valid 
value for subprocess.Popen parameters) would suppress stdout/stderr and None 
would be meaningful to say 'inherit from parent process'. In this way this 
would be an addition to subprocess.Popen semantic, but it would be 
counter-intuitive to the possibility of redirecting to, say, another file.
2) redirect_stdout/redirect_stderr. Actually this was my first thinking when 
implementing this, but it has the same problems, IMHO, of the plain 
stdout/stderr and in the end this is why I chose the latter.

Does this make sense?

Cristian

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22277>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to