4 ms·

I looked at the source code. Under the hood, it's just a thin wrapper around `subprocess`.

• asdfgadsfgasfdg 9y ago
  Cool subprocess is a little verbose. But did you happen to notice if it executes with shell=True or shell=False?
  • mintplant 9y ago
    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-subprocess-module https://docs.python.org/3/library/subprocess.html#using-the-...
    • icebraining 9y ago
      Doesn't seem that different from call()
      • asdfgadsfgasfdg 9y ago
        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.
    • asdfgadsfgasfdg 9y ago
      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().