On Jan 29, 2015 3:11 PM, "Thomas Kluyver" thomas@kluyver.me.uk wrote:
On 29 January 2015 at 03:47, Nick Coghlan ncoghlan@gmail.com wrote:
I still suspect we should be offering a simpler way to decouple the creation of the pipes from the subprocess call, but I have no idea what that API should look like,
Presumably that would need some kind of object representing a
not-yet-started process. Technically, that could be Popen, but for backwards compatibility the Popen constructor needs to start the process, and p = Popen(..., start=False) seems inelegant.
Let's imagine it's a new class called Command. Then you could start
coming up with interfaces like:
c = subprocess.Command(...) c.stdout = fileobj c.stderr = fileobj2 # Or c.capture('combined') # sets stdout=PIPE and stderr=STDOUT # Maybe get into operator overloading? pipeline = c | c2 # Could this work? Would probably require threading c.stdout = BytesIO() c.stderr_decoded = StringIO() # When you've finished setting things up c.run() # returns a Popen instance
N.B. This is 'thinking aloud', not any kind of proposal - I'm not
convinced by any of that API myself.
Here's a start at adding an 'expect_returncode' to sarge.
I really like the sarge .run() and Capture APIs:
* http://sarge.readthedocs.org/en/latest/overview.html#why-not-just-use-subpro... * http://sarge.readthedocs.org/en/latest/tutorial.html#use-as-context-managers