[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