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-front. So the encouragement should be clear. Simply put, there is no valid use case for os.system over subprocess by remaining it must be considered redundant. On Wed, Oct 24, 2018 at 7:58 AM Steve Dower wrote:

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 purpose.

Agreed.

There are two different groups of users involved here. People developing scripts to run on their own machines (super-shell scripts, if you like), and people developing applications/libraries to run on other machines.

The latter case should *definitely* be using subprocess, because they shouldn't be making assumptions about what shell is being used.

The former case should be able to use os.system if that satisfies their needs, without seeing warnings that make them think they can't write the simplest code that works anymore.

If that means changing *some* of the other references in the docs, then I'm okay with that. But both uses are valid, so it's really more about being clear who the function is intended for.

Cheers, Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cspealma%40redhat.com

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 process returncode. https://sarge.readthedocs.io/en/latest/ https://docs.python.org/3/library/os.html#os.system https://github.com/python/cpython/blob/master/Modules/posixmodule.c https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncod... https://docs.python.org/3/library/subprocess.html#subprocess.call https://docs.python.org/3/library/subprocess.html#subprocess.check_call https://en.wikipedia.org/wiki/System_call https://en.wikipedia.org/wiki/Exec_(system_call) ... "ENH: Add call, check_call, check_output, CalledProcessError, expect_returncode" https://bitbucket.org/vinay.sajip/sarge/pull-requests/1/enh-add-call-check_c... On Wednesday, October 24, 2018, Steve Dower wrote:

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 ways to run system commands, and many non-obvious ways to manage subprocesses.

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-front. So the encouragement should be clear.

Agreed. One good heuristic is whether you're putting the system command in a function or not, since functions are explicitly designing for reuse while just using it in a script is not.

Simply put, there is no valid use case for os.system over subprocess by

...

remaining it must be considered redundant.

You have not shown this. Posting quotes followed by an unrelated conclusion isn't a very compelling form of argument :)

Cheers, Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes. turner%40gmail.com

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.system. If you depreciate and then remove os.system, all you will do is force people to re-invent it, badly and inefficiently.

by remaining it must be considered redundant.

And neither is that. os.system is not redundant, as its purpose is different from that of subprocess. -- Steve

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, badly and inefficiently.

Indeed. Usability counts, as does not arbitrarily breaking vast amounts of existing code that Just Works. Every code-breaking deprecation is an invitation for unseen thousands or millions to ponder, "Hm, this script doesn't work anymore. Maybe now is the time to look at Node or Rust." -Peter

On Thu, 25 Oct 2018 at 22:00, Nick Coghlan wrote:

On Thu, 25 Oct 2018 at 01:34, Calvin Spealman wrote:

...

Simply put, there is no valid use case for os.system over subprocess by remaining it must be considered redundant.

They do different things. The warnings against using os.system are based on "If you don't know whether or not you have the use case that this exists to handle it's much safer to assume that you don't", not "This has no valid use cases" (your use case just has to meet the criteria that makes os.system safe to use - no exposure to untrusted input.

Whoops, hit send without finishing the sentence: no exposure to untrusted input, no need for cross-platform compatibility, no need for assistance with getting string quoting right, no need for significant interaction with the child process. os.system is a good thing for linters (especially security linters) to warn about, since running a linter over something is a decent hint that you're not writing a throwaway script, and if folks *are* running a linter against their ad hoc scripts, it's reasonably to expect them to configure it for their personal preferences. It isn't actively blocking the development of higher level alternatives though, so there isn't a good reason to deprecate it and break working code. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

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 scripting more difficult. That being said, if there are examples in the docs that use os.system() that have a good reason to use subprocess, then by all means, let's update those. Also: a point was made there that using os.system is essentially making an assumption about teh shell in use, and thsu is not very portable accross systems. MAybe that point could be explicitly added to the docs, rather than just: "more powerful facilities for spawning new processes and retrieving their results;" When I read that, I think "system is working fine, I don't need more powerful facilities for spawning new processes or anything special in retrieving their results;" So more info, right there, about WHY you would want to use subprocess instead would be helpful. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov