On Jan 29, 2015 3:11 PM, "Thomas Kluyver" <firstname.lastname@example.org> wrote:
> On 29 January 2015 at 03:47, Nick Coghlan <email@example.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: