On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
the popen2 module at all, and do everything via the subprocess module.
I wonder if we should even get rid of os.system(); then there should
be a subprocess.system()
On 3/23/07, Hrvoje Nikšić [EMAIL PROTECTED] wrote:
On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
the popen2 module at all, and do everything via the subprocess module.
I wonder if we should even get rid of
On Fri, Mar 23, 2007 at 10:30:37AM -0600, Steven Bethard wrote:
- On 3/23/07, Hrvoje Nik??i?? [EMAIL PROTECTED] wrote:
- On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
- Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
- the popen2 module at all, and do
Hi all,
I posted about adding 'get_output', 'get_status_output', and
'get_status_output_errors' to subprocess here,
http://ivory.idyll.org/blog/mar-07/replacing-commands-with-subprocess
and got some interesting responses.
Briefly, my original proposal was to add these three functions:
Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
the popen2 module at all, and do everything via the subprocess module.
I wonder if we should even get rid of os.system(); then there should
be a subprocess.system() instead. And do we even need os.fork(),
os.exec*(),
Guido van Rossum schrieb:
Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
the popen2 module at all, and do everything via the subprocess module.
I wonder if we should even get rid of os.system(); then there should
be a subprocess.system() instead. And do we even need
\Martin v. Löwis\ [EMAIL PROTECTED] wrote:
And do we even need os.fork(), os.exec*(), os.spawn*()?
I don't know about about *os*.fork; I surely like to have posix.fork.
The posix module exposes many OS functions as-is. This has the
advantage that their semantics are crystal-clear: they do
On 3/22/07, Jon Ribbens [EMAIL PROTECTED] wrote:
\Martin v. Löwis\ [EMAIL PROTECTED] wrote:
And do we even need os.fork(), os.exec*(), os.spawn*()?
I don't know about about *os*.fork; I surely like to have posix.fork.
The posix module exposes many OS functions as-is. This has the
Guido van Rossum wrote:
On 3/22/07, Jon Ribbens [EMAIL PROTECTED] wrote:
\Martin v. Löwis\ [EMAIL PROTECTED] wrote:
And do we even need os.fork(), os.exec*(), os.spawn*()?
I don't know about about *os*.fork; I surely like to have posix.fork.
The posix module exposes many
Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
that abomination invented by Microsoft?
Right, I personally would not miss it. It's also not a system call,
but a library function on both Windows and Unix (the equivalent
of exposing fork would be to expose CreateProcessEx -
On Thu, Mar 22, 2007 at 09:34:46PM +, Michael Foord wrote:
- Guido van Rossum wrote:
- Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
- that abomination invented by Microsoft? I also hear no opposition
- against killign os.system() and os.popen()
-
- Except that
Guido van Rossum [EMAIL PROTECTED] wrote:
Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
that abomination invented by Microsoft? I also hear no opposition
against killign os.system() and os.popen().
As long as os.system migrates to subprocess.system (as you originally
On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
that abomination invented by Microsoft? I also hear no opposition
against killign os.system() and os.popen()
Except that 'os.system' is really
Titus Brown wrote:
On Thu, Mar 22, 2007 at 09:34:46PM +, Michael Foord wrote:
- Guido van Rossum wrote:
- Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
- that abomination invented by Microsoft? I also hear no opposition
- against killign os.system() and
On Thu, Mar 22, 2007 at 02:47:58PM -0700, Guido van Rossum wrote:
- On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote:
- Guido van Rossum wrote:
- Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
- that abomination invented by Microsoft? I also hear no opposition
-
* Titus Brown wrote:
On Thu, Mar 22, 2007 at 02:47:58PM -0700, Guido van Rossum wrote:
- On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote:
- Guido van Rossum wrote:
- Sure. os.fork() and the os.exec*() family can stay. But
os.spawn*(), - that abomination invented by Microsoft? I also
On Thu, Mar 22, 2007 at 11:12:26PM +0100, Andr? Malo wrote:
- * Titus Brown wrote:
-
- On Thu, Mar 22, 2007 at 02:47:58PM -0700, Guido van Rossum wrote:
- - On 3/22/07, Michael Foord [EMAIL PROTECTED] wrote:
- - Guido van Rossum wrote:
- - Sure. os.fork() and the os.exec*() family can
Titus Brown wrote:
* second, I'd like to add a 'require_success' bool keyword, that is
by default False (and does nothing in that case). However, when
True, the functions would emulate check_call, i.e. they would raise
CalledProcessError when the returncode was not zero.
By the
Guido van Rossum wrote:
I wonder if we should even get rid of os.system(); then there should
be a subprocess.system() instead.
That sounds okay, since system() isn't actually a system call,
despite its name.
And do we even need os.fork(), os.exec*(), os.spawn*()?
Since fork() and exec()
Titus Brown wrote:
I could add in a 'system'-alike call easily enough; that was suggested.
But I think
returncode = subprocess.call(program)
is pretty simple, isn't it?
Something to keep in mind is that system() doesn't
directly launch a process running the command, it
uses a
On 22 Mar, 08:38 pm, [EMAIL PROTECTED] wrote:
And do we even need os.fork(), os.exec*(), os.spawn*()?
Maybe not os.spawn*, but Twisted's spawnProcess is implemented (on UNIX)
in terms of fork/exec and I believe it should stay that way. The
subprocess module isn't really usable for
On 22 Mar, 09:37 pm, [EMAIL PROTECTED] wrote:
Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
that abomination invented by Microsoft?
Right, I personally would not miss it. It's also not a system call,
but a library function on both Windows and Unix (the equivalent
of
On 3/22/07, Greg Ewing [EMAIL PROTECTED] wrote:
Titus Brown wrote:
I could add in a 'system'-alike call easily enough; that was suggested.
But I think
returncode = subprocess.call(program)
is pretty simple, isn't it?
Something to keep in mind is that system() doesn't
On 3/16/07, Titus Brown [EMAIL PROTECTED] wrote:
- What about reimplementing commands.* using subprocess? Or providing a
- commands.*-compatible interface in the subprocess module?
OK, so as I understand it, the next step would be for me to provide a
patch implementing this, right? Or is
On 3/16/07, Titus Brown [EMAIL PROTECTED] wrote:
- Yes. Another intermediate step might be to rewrite the commands module
- to call the new APIs in the subprocess module.
My preference would be to push people towards subprocess, and the more
capable complex API there, by deprecating commands
On Tue, Mar 13, 2007 at 02:16:21PM -0700, Guido van Rossum wrote:
- On 3/13/07, Georg Brandl [EMAIL PROTECTED] wrote:
- I'd like to deprecate commands.getstatus() in 2.6.
-
- Reason: there is getoutput() and getstatusoutput(). In the latter, status
- means the exit code. getstatus(), however,
On Tue, Mar 13, 2007 at 04:55:07PM -0700, Guido van Rossum wrote:
- On 3/13/07, Titus Brown [EMAIL PROTECTED] wrote:
- What about reimplementing commands.* using subprocess? Or providing a
- commands.*-compatible interface in the subprocess module?
-
- What does that buy us?
The simplicity of
- What about reimplementing commands.* using subprocess? Or providing a
- commands.*-compatible interface in the subprocess module?
OK, so as I understand it, the next step would be for me to provide a
patch implementing this, right? Or is this PEP-required (please no...)?
What do people
On Fri, Mar 16, 2007 at 09:50:29AM -0700, Guido van Rossum wrote:
- What do people think of this basic interface?
-
- (status, output) = subprocess.get_status_output(cmd)
-
- output = subprocess.get_output(cmd)
-
- Here 'status' is the 'returncode' from subprocess.Popen, and
On Tue, Mar 13, 2007 at 04:55:07PM -0700, Guido van Rossum wrote:
What does that buy us?
subprocess offers better error-trapping, I think, and additional
features such as closing all file descriptors after forking. At work,
I found this fixed a number of bugs in our daemons code because if you
Guido van Rossum wrote:
What about reimplementing commands.* using subprocess? Or providing a
commands.*-compatible interface in the subprocess module?
What does that buy us?
multi-platform support? (commands is Unixoid only, right?)
/F
___
Alright already! It wasn't a thetorical question, and I'm convinced! :-)
On 3/14/07, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What about reimplementing commands.* using subprocess? Or providing a
commands.*-compatible interface in the subprocess module?
What does
I'd like to deprecate commands.getstatus() in 2.6.
Reason: there is getoutput() and getstatusoutput(). In the latter, status
means the exit code. getstatus(), however, returns the output of ls -ld
file which is completely nonobvious and confusing.
Perhaps the whole commands module can be
On 3/13/07, Georg Brandl [EMAIL PROTECTED] wrote:
I'd like to deprecate commands.getstatus() in 2.6.
Reason: there is getoutput() and getstatusoutput(). In the latter, status
means the exit code. getstatus(), however, returns the output of ls -ld
file which is completely nonobvious and
Guido van Rossum schrieb:
On 3/13/07, Georg Brandl [EMAIL PROTECTED] wrote:
I'd like to deprecate commands.getstatus() in 2.6.
Reason: there is getoutput() and getstatusoutput(). In the latter, status
means the exit code. getstatus(), however, returns the output of ls -ld
file which is
On 3/13/07, Titus Brown [EMAIL PROTECTED] wrote:
What about reimplementing commands.* using subprocess? Or providing a
commands.*-compatible interface in the subprocess module?
What does that buy us?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
36 matches
Mail list logo
