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-subprocess
* http://sarge.readthedocs.org/en/latest/tutorial.html#use-as-context-managers