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, an
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
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.syste
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
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 expo
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 asynchrono
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
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:
> * 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
On 3/22/07, Guido van Rossum <[EMAIL PROTECTED]> 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 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*(
* 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 Micr
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 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() an
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
"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 origina
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 th
> 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
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
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. Thi
"\"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-clea
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
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*(), os.spawn*()
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:
ou
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
-> > >> 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 pe
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 simpl
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(
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
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
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?
> >
>
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?)
_
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
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/)
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
>> " wh
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
> " which is completely nonobvious and
36 matches
Mail list logo
