(original) (raw)

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.

Is that way? I didn't find it particularly hard to learn, given the "cheat sheet" of techniques for doing the replacements.

However, it is a bit deficient in providing non-blocking handling primitives for actually communicating with interactive spawned programs. subprocess.communicate provides one technique, which works for an extremely limited set of circumstances: I've offered some alternatives in http://bugs.python.org/issue10482 that greatly expand the types of communications that can be achieved without deadlock. Of course, it is still a small fraction of the possible circumstances, and doesn't really handle the hard case of feeding a program and concurrently analyzing its output to determine its future feedings: that still requires a complex, explicitly threaded and synchronized program.