[issue22442] Deprecate PIPE with subprocess.check_call() and call()

2020-12-12 Thread Irit Katriel
Change by Irit Katriel : -- resolution: -> out of date stage: patch review -> resolved status: pending -> closed ___ Python tracker ___ ___

[issue22442] Deprecate PIPE with subprocess.check_call() and call()

2020-11-11 Thread Irit Katriel
Irit Katriel added the comment: Any objections to closing this? If the old API is going to be deprecated I think that's a topic for another issue. -- nosy: +iritkatriel status: open -> pending ___ Python tracker

[issue22442] Deprecate PIPE with subprocess.check_call() and call()

2015-06-21 Thread Berker Peksag
Changes by Berker Peksag : -- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 ___ Python tracker ___ ___

[issue22442] Deprecate PIPE with subprocess.check_call() and call()

2015-06-21 Thread Akira Li
Akira Li added the comment: Martin, thank you for the review. As Matthias mentioned, the introduction of subprocess.run() perhaps deprecates this issue: old api should be left alone to avoid breaking old code, new code should use new api, those who need old api (e.g., to write 2/3 compatible

[issue22442] Deprecate PIPE with subprocess.check_call() and call()

2015-06-01 Thread Matthias Bussonnier
Matthias Bussonnier added the comment: 3.5 have `subprocess.run`[1] that is much saner to use, and what you want to use in most cases. `call` and `check_call` docs even mention run. [1]: https://docs.python.org/3.5/library/subprocess.html#subprocess.run -- nosy: +mbussonn

[issue22442] Deprecate PIPE with subprocess.check_call() and call()

2015-06-01 Thread Martin Panter
Martin Panter added the comment: I agree with the deprecation idea. The parameter checking logic doesn’t seem right though; see Reitveld. Also, I would have made the warning specify exactly what is deprecated, in case the stack trace doesn’t identify the function, which I think would always ha