[Python-Dev] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
v+python at g.nevcal.com
Mon Dec 6 00:55:43 CET 2010
On 12/5/2010 10:03 AM, skip at pobox.com wrote:
> Glenn> On 12/4/2010 3:07 PM, Paul Moore wrote:
> >> The original goal was for subprocess to replace os.system, os.popen,
> >> os.spawn, etc. That's never quite happened because subprocess is just
> >> a little bit too conceptually complex for those basic tasks.
> Glenn> Is that way? I didn't find it particularly hard to learn, given
> Glenn> the "cheat sheet" of techniques for doing the replacements.
> For 99% of my usage (I suspect for most other peoples' as well, at least on
> Unix-y systems), this is all I need:
> for line in os.popen("some pipeline"):
> No cheat sheet necessary. I don't see how subprocess could have made that
> common idiom any simpler. Maybe it's better at doing esoteric stuff,
> however that falls into the 1% where a simple os.popen isn't adequate.
So it couldn't make it any simpler. For your 99% usage, the question
is, does it make it harder? And the answer is, at least a little bit...
you have to type more...
for line in subprocess.Popen("cmd", shell=True, stdout=PIPE).stdout:
Sad. It does seem like some wrapper functions could have been provided
to make the easy cases at least as easy as they were before...
My 99% case involves web servers and CGI-type interfaces. And
subprocess doesn't provide quite enough to handle the job. It is a bit
more complex than your pipeline case, and subprocess does allow the job
to be done, and allows it to be done better than popen or popen2 could
ever do it. But the helper functions I suggest in the issue would make
it lots easier. And probably, it would be nice to include starting the
threads within the helper functions, too.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev