Background: Tulip issue 115 ( http://code.google.com/p/tulip/issues/detail?id=115).
Victor and I are trying to design a "convenience API" for subprocess management in Tulip. This would be an API that wraps the existing low-level APIs loop.subprocess_shell() and loop.subprocess_exec(), but instead of requiring you to implement a SubprocessProtocol subclass, just give you a StreamWriter connected to the subprocess's stdin and StreamReaders connected to its stdout and stderr. Unfortunately any API for subprocess management just has a lot of features, and we're having a hard time coming up with a reasonably convenient API that is still flexible. Here are some concerns -- the problem is, taken literally, all these requirements are contradictory, so we could use some help prioritizing them. - Ideally the APIs would take the same arguments as subprocess_shell/exec, except for the protocol factory. The return value may be different. - Ideally there would be parallel APIs for subprocess_shell and _exec (which only differ in how you specify the subprocess -- the former takes a string in shell syntax, the latter uses an argv-style list of strings). - We need access to subprocess features like its pid, its exit status (once it's exited), and we want to be able to send it signals and wait for its completion. - We want to support separate streams wrapping the pipes for stdin, stdout, and stderr, but we may not need all three, and it's probably asking for trouble to return all three by default, since it's easy to get a deadlock if the same task alternates between reading from stdout and writing to stdin (however, if you use separate tasks it's a manageable problem). - We'd like the API to either resemble the event loop subprocess API (which we're not changing), or the existing non-Tulip subprocess API (the subprocess module, or possibly the various subprocess management functions in the os module), rather than designing yet another API. - We'd also like to reuse the StreamReader and StreamWriter classes already in Tulip. We've already refactored these slightly to support the new use case -- check out the Tulip repo. Any suggestions or insights would be appreciated. -- --Guido van Rossum (python.org/~guido)
