I hadn't actually noticed that! It looks like .run() allows input and output to be piped and the return code captured. That is a serious improvement over subprocess.call().
It looks like it allows stdin, stdout, stderr and return code to be handled properly which call() doesn't. It's still syntactic sugar over Popen() and communicate() but will cut down boilerplate for calling external processes.
Comments
Cool subprocess is a little verbose. But did you happen to notice if it executes with shell=True or shell=False?
Do you include Python 3.5's subprocess.run in that assessment? I find it much cleaner for the common cases than the rest of the API:
https://docs.python.org/3/library/subprocess.html#using-the-...
I hadn't actually noticed that! It looks like .run() allows input and output to be piped and the return code captured. That is a serious improvement over subprocess.call().
Doesn't seem that different from call()
It looks like it allows stdin, stdout, stderr and return code to be handled properly which call() doesn't. It's still syntactic sugar over Popen() and communicate() but will cut down boilerplate for calling external processes.