[Python-3000] os.popen versus subprocess.Popen
Guido van Rossum
guido at python.org
Tue Apr 22 21:52:04 CEST 2008
On Tue, Apr 22, 2008 at 8:57 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/4/22, Guido van Rossum <guido at python.org>:
> > I still think os.popen() should be reimplemented on top of subprocess,
> > and add the same optional flags as the open() function has grown to
> > indicate encoding and buffering.
>
> os.popen() is deprecated in 2.6, with the recommendation of using the
> subprocess module.
I forgot about that. Well, I propose to undeprecate it or at lest
replicate it as subprocess.popen().
> In view of this, I'm always recommending to use os.system() for easy
> execution (no control), and the subprocess.Popen() for full control
> (not so easy to use).
>
> I agree that it should appear a more easy to use function, and also
> agree that it should be constructed over subprocess.Popen(). But, as
> all os.popen* functions are deprecated, and it will be constructed
> over subprocess.Popen(), I think that this easy-to-use function should
> be in the subprocess module.
Good plan.
> BTW, the top two complains about subprocess.Popen "complicated API" in
> the Python Argentina mail list and the courses I give, are:
>
> - Why can't I write "ls -l", instead of ["ls", "-l"] (people ends
> writing "ls -l".split())
There's a flag that will make it do that for you (I think it's called
shell or some such).
> - The parameter stdout should default to subprocess.PIPE
That depends on what you want to do with the output. I think it's fine as it is.
> Maybe we could use this feedback for the ease-to-use function.
IMO the easy-to-use function should replicate os.popen() closely.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list