Raymond Hettinger added the comment:
Sorry, I'm rejecting this. No reasons were presented that would warrant such
as disruptive change.
For good or ill, a number of languages implement the same call in much the same
way. It does its job of exposing an operating system service that many peop
R. David Murray added the comment:
I wasn't around when that decision was made, but looking at the posixmodule.c
source, system is a straightforward wrapper, but popen gets...byzantine on
anything but unix.
--
nosy: +r.david.murray
___
Python track
Skip Montanaro added the comment:
Eric> Note that os.popen is implemented with subprocess.
That seems somewhat wrong to me. There is a stdio popen function which
os.popen used to expose. I thought that was the goal (thin wrapper around
many library functions, then build higher level stuff on
Éric Araujo added the comment:
Note that os.popen is implemented with subprocess. For os.system, what Raymond
said: It complies with the Python habit of exposing calls as is, and its
documentation already advertises subprocess.
--
nosy: +eric.araujo
_
Raymond Hettinger added the comment:
I'm inclined to reject this out-of-hand. The os.system() call is a basic call
that had been around for very long time, has been widely used successfully, and
has parallels in other languages.
Please elaborate on "is broken i several fundamental ways."
--
Skip Montanaro added the comment:
I disagree. Both os.popen and os.system work fine in the proper context
and are easier to use (and remember how to use) than the subprocess
module. You don't give any examples of breakage, or whether said
breakage is platform-dependent.
--
nosy: +skip
New submission from Jakob Bowyer :
os.system is broken in several fundamental ways. We already have the subprocess
module for accessing other processes, lets send os.system the same way as
os.Popen.
--
components: Library (Lib)
messages: 126995
nosy: Jakob.Bowyer
priority: normal
sever
