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