Guido also comments the issue, but I prefer to reply here. Guido: > Perhaps we should go further and add all the convenience methods and > constants from the subprocess module too? E.g. > call() > check_call() > check_output() > DEVNULL > STDOUT > PIPE
Be careful, some subprocess has known flaws. For example, getoutput() and getstatusoutput() use shell=True which is dangerous and leads to the trap explained in my previous email (['echo', 'Hello World!'] doesn't return 'Hello World!'). If we adds specific constants like PIPE and DEVNULL, they should be added to an asyncio submodule (ex: asyncio.subprocess) to not pollute asyncio namespace. If the Python standard library is rewritten to work with asyncio, we may get more submodules (ex: asyncio.http.client, asyncio.telnet, etc.). > Which reminds me -- I do like the idea that the returned object is not itself > a Protocol object but just holds a reference to one -- so clueless users > can't try to call Protocol methods like connection_closed(). Do you mean that the new class would have to delegate all methods to SubprocessStreamProtocl which delegates to BaseSubprocessTransport? > And do we need close()? (Maybe -- what's the use case? Popen doesn't have > it.) It can be dropped. Victor
