<Caveat: not really up to speed with the current state of asyncio, but *have* spent quite a bit of time trying to make the existing subprocess module more usable through docs and convenience functions>
On Wednesday, January 29, 2014 9:38:36 PM UTC+10, Andrew Svetlov wrote: > > When I proposed to add subprocess_shell/subprocess_exec I was keeping in > mind http://bugs.python.org/issue7839 > Still think that copying suboptimal desing in new library is bad idea. > Right, separate shell/exec interfaces are a better approach. Changing that doesn't seem to be being suggested, though. > About None/PIPE as default for stdin, stdout and stderr. > None links to parent's standard streams, right? > Perhaps it's good for simple console script which executes some commands > like sh/bash does. I assumed that behavior is not perfect for reactive > systems with running event loop. > Say, if you don't need stderr so maybe DEVNULL is better? > I suspect changing the standard stream defaults away from those of subprocess isn't worth the confusion it would cause users. > Returning from create_subprocess_* some facade without public protocol > method is good idea. That object should look like subprocess transport > with streams, not protocol -- as we have separate StreamReaderProtocol and > StreamReader itself. > I like Victor's suggestion of using the basic attribute and method structure of subprocess.Popen, just adapted to asyncio - it immediately made sense to me, and I'm probably a good test subject for that (familiar with subprocess, and while I remember the general concepts, it's been a *long* time since I read the details of PEP 3156). > I'm ok with .returncode. > .poll() is not required, yield from proc.wait() should be enough. > The same for .communicate(), I this this method was invented to hide > complexness of working with *blocking* stdstreams and contains > micro-event-loop inside. > Yes, the event loop in the parent will inherently interleave reads from the stdout and stderr pipes (if defined), even if the task itself is waiting to finish writing data. > > call()/check_call()/check_output() -- don't know. > Those are three very common patterns for invoking child processes, so well worth supporting. You could probably live without the "shell=True" variants and make people drop down to the lower level API for shell invocation, though. Cheers, Nick.
