On Tue, Apr 22, 2008 at 8:57 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/4/22, Guido van Rossum <[EMAIL PROTECTED]>: > > 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com