My take on this is that os.system() is there because it's part
of the C stdlib, and Python generally aims to provide wrappers
for all of the C stdlib facilities. It's not Python's place to
start making value judgements about which things are worthy of
being wrapped and which aren't.
--
Greg
On Wed, Oct 24, 2018 at 3:31 PM Steven D'Aprano wrote:
> On Wed, Oct 24, 2018 at 09:34:34AM -0400, Calvin Spealman wrote:
>
> > Simply put, there is no valid use case for os.system over subprocess
>
> If you depreciate and then remove os.system, all you will do is force
> people to re-invent it,
The os module is by definition special. It exposes libc and platform
APIs. That there are Python modules that provide similar functionality,
often surpassing it and sometimes being built on top of it, is
intentional. Random quotes from the Zen don't win arguments. Although
practicality beats pu
On Wed, Oct 24, 2018 at 09:34:34AM -0400, Calvin Spealman wrote:
> Simply put, there is no valid use case for os.system over subprocess
That is simply not true. That's your opinion, masquerading as a fact,
and made in the face of Steve Dower's description of at least one
appropriate use of os.
On 24/10/18 14:34, Calvin Spealman wrote:
In the spirit of "There should be one-- and preferably only one
--obvious way to do it." this makes perfect sense.
The distinction between "your own machine and other peoples machines" is
not always clear, nor planned for, nor understood by developers
On Wed, Oct 24, 2018 at 9:06 AM, Victor Stinner wrote:
> I like os.system() and use it everyday.
me too.
Python has been evolved over the years away from a "scripting language",
and becoming more of a "systems language". Which is mostly a good thing,
but no need to gratuitously make quick scri
I like os.system() and use it everyday. I prefer to write
os.system("grep ^Vm /proc/%s/status" % os.getpid()) than... much more
Python code to do the same thing, or subprocess.run("grep ^Vm
/proc/%s/status" % os.getpid(), shell=True):
os.system() is shorter and only requires "import os" :-)
I'm n
In the spirit of "There should be one-- and preferably only one --obvious
way to do it." this makes perfect sense.
The distinction between "your own machine and other peoples machines" is
not always clear, nor planned for, nor understood by developers to be an
important distinction to make up-fron
Sarge is one way to appropriately wrap Process Control (with shell-like
piping of stdin and stdout between multiple processes).
os.system just calls C system(), AFAIU
subprocess.call calls subprocess.Popen, which does far more than just
wrapping C system(); though the return value is also the pro
On 24Oct2018 0934, Calvin Spealman wrote:
In the spirit of "There should be one-- and preferably only one
--obvious way to do it." this makes perfect sense.
To do what? There is one obvious way to run a system command, and one
obvious way to manage subprocesses. There are also many non-obvious
On 24Oct2018 0435, Antoine Pitrou wrote:
On Wed, 24 Oct 2018 08:05:21 +0200
Stephane Wirtel wrote:
1. Add the 'deprecated' directive in the doc
2. Use subprocess for these references
What is your opinion?
I don't think it's useful to deprecate something that works fine for
the intended purpo
On Wed, 24 Oct 2018 08:05:21 +0200
Stephane Wirtel wrote:
> Good morning/afternoon/evening/night ;-)
>
> In the documentation of os.system [1], there is this paragraph, where we
> suggest to use subprocess instead of os.system.
>
> """
> The subprocess module provides more powerful facilities fo
12 matches
Mail list logo
