Why is python's subprocess.call implemented like this?

Question

The subprocess module has the convenience function call, which is implemented like this in both 2.6 and 3.1:

def call(*popenargs, **kwargs):
    ret         


        

Answer 1

If all you want to do is run a command and get the exit status to determine if it succeeded or failed then you don't need to communicate with it via pipes. That's the convenience of the subprocess.call() method. There are other convenience functions in the subprocess module as well which encapsulate many of the common uses of using the Popen objects in an efficient manner.

If you need to pipe the child processes stdout or stderr somewhere than don't use call(), use a Popen object and communicate() with it just as the docs state.

Answer 2

I spent some time looking through PEP-324, which introduced the subprocess module, trying to figure out the design decisions involved, but I think the answer is actually very simple:

There's no reason to pass stdout=PIPE or stderr=PIPE to subprocess.call, so the fact that it can deadlock is irrelevant.

The only reason to pass stdout=PIPE or stderr=PIPE to subprocess.Popen is so that you can use the Popen instance's stdout and stderr attributes as file objects. Since subprocess.call never lets you see the Popen instance, the PIPE options become irrelevant.

There is potential overhead to Popen.communicate (creating additional threads to avoid deadlock by monitoring the pipes), and there's no benefit in this case, so there's no reason to use it.

Edit: If you want to discard your output, I guess it's better to do so explicitly:

# option 1
with open(os.devnull, 'w') as dev_null:
    subprocess.call(['command'], stdout=dev_null, stderr=dev_null)

# option 2
subprocess.call(['command >& /dev/null'], shell=True)

instead of instructing subprocess to capture all of the output to PIPE files that you never intend to use.