This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients docs@python, josh.r, pekka.klarck
Date 2018-04-20.17:26:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1524245163.19.0.682650639539.issue33319@psf.upfronthosting.co.za>
In-reply-to
Content
If the goal is just to suppress stdout, that's what passing subprocess.DEVNULL is for (doesn't exist in Py2, but opening os.devnull and passing that is a slightly higher overhead equivalent).

subprocess.run includes a call to communicate as part of its default behavior, and stores its results, so call() isn't quite equivalent to run().returncode when PIPE was passed for standard handles, because call only includes an implicit call to wait, not communicate, and therefore pipes are not explicitly read and can block.

Basically, subprocess.run is deadlock-safe (because it uses communicate, not just wait), but if you don't care about the results, and the results might be huge, don't pass it PIPE for stdout/stderr (because it will store the complete outputs in memory, just like any use of communicate with PIPE).

The docs effectively tell you PIPE is safe; it returns a CompletedProcess object, and explicitly tells you that it has attributes that are (completely) populated based on whether capture was requested. If it had such attributes and still allowed deadlocks, it would definitely merit a warning.
History
Date User Action Args
2018-04-20 17:26:03josh.rsetrecipients: + josh.r, docs@python, pekka.klarck
2018-04-20 17:26:03josh.rsetmessageid: <1524245163.19.0.682650639539.issue33319@psf.upfronthosting.co.za>
2018-04-20 17:26:03josh.rlinkissue33319 messages
2018-04-20 17:26:03josh.rcreate