should these be fixed for python 2.4?

[Grant Edwards]

It's also cumbersome to use and I worry that some day
it will disapper. Does anyone actually use the 'commands'
module?

I do.

 

[Nick Craig-Wood]

Thanks -- I didn't know about that (small wonder -- it's undocumented; no
docstring and not in the manual).

....and doesn't do the right thing on windows - see my other posting in
this thread!

 

[Alexander Schmolck]

...and doesn't do the right thing on windows - see my other posting in
this thread!

Yes, that's why I mentioned the need for a "documented and *reasonably
reliable*" version in another post (the code also happens to be terribly
inefficient, but that's presumably not such a big concern).

'as

 

[Carlos Ribeiro]

On Sun, 03 Oct 2004 15:50:18 +0100, Alexander Schmolck

reliable*" version in another post (the code also happens to be terribly
inefficient, but that's presumably not such a big concern).

Shouldn't it be easier (and less contentious) to add the 'run'
function to the commands module? I mean, messing with the os module
may be a little bit harder, because most calls there simply mimic the
standard library calls. Convenience functions (such as run()) could go
elsewhere, and commands is a nice candidate -- you can use it to check
return values, and similar stuff.

Of course -- the docs should be updated, and os.system *should* point
to (commands.run | os.run | whatever) as a good convenience
alternative.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Alexander Schmolck]

On Sun, 03 Oct 2004 15:50:18 +0100, Alexander Schmolck


Shouldn't it be easier (and less contentious) to add the 'run' function to
the commands module? I mean, messing with the os module may be a little bit
harder, because most calls there simply mimic the standard library calls.

Well, I'm not particularly enamoured with the commands module (and it's unix
only). As long as the docs of os point in the right direction I'm not that
fuzzed where the functionality ends up, but I must say I find this "thin
wrapper" argument unconvincing -- it might be a great argument for not messing
with `system` (people expect it to work like the C-counterpart), but I don't
see why it would preclude an `os.run`:

a) os already contains plenty of convinience functions that don't have
C-counterparts (removdirs, walk etc.) and generally it is not just an
"close to the metal" type module, but simply what is used for the majority
of os relevant stuff.

b) As such, it is not just used by a select few system programmers, but simply
by about everyone who wants to use python for scripting. Given that python
is intended as a scripting language particularly also for people who don't
spend all their lives in front of computers and given that in this specific
instance it performs poorly at that combination (inexperienced folks are
needlessly likely to produce broken code for a fairly frequent and simple
task and that even remains true for experienced programmers -- several
regulars have claimed in this thread that they either got bitten by
os.system or at least found the spawn* stuff difficult to use and to
remember) my personal feeling is that the addition of `run` is well worth
the "bloat".

Anyway, I think this horse has now been beaten to death -- either someone who
has the power to make inclusions has been convinced by now or it's not gonna
happen (at least not in the immediate future).


'as

 

[Robert Kern]

Alexander Schmolck wrote:

[snip]

Anyway, I think this horse has now been beaten to death -- either someone who
has the power to make inclusions has been convinced by now or it's not gonna
happen (at least not in the immediate future).

Not necessarily. It *is* unlikely that someone who "has the power to
make inclusions" is going to pick up on this and write an implementation
for you. However, (and this is an important feature of Python's
development) if *you* write an implementation, document it, write unit
tests for it, and present it to the public and python-dev with a good
case for its existence, it has a pretty good chance of getting in.

Many (most?) of the active Python core developers don't read c.l.py with
any frequency. If you have a feature request, post it to the Sourceforge
bug tracker[1], preferably with a patch implementing the feature, or
it's almost certain that no-one will pick it up.

[1] http://sourceforge.net/tracker/?group_id=5470

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Alexander Schmolck]

Not necessarily. It *is* unlikely that someone who "has the power to make
inclusions" is going to pick up on this and write an implementation for
you.

Well, the implementation is quite trivial (and I've posted one).

However, (and this is an important feature of Python's development) if *you*
write an implementation, document it, write unit tests for it, and present
it to the public and python-dev with a good case for its existence, it has a
pretty good chance of getting in.

Sure, but Martin von Loewis suggested posting a patch for one of my gripes
(pydoc) -- which I did, but didn't think this one substantiated, which
suggests to me that inclusion is not that likely. And whether it gets in is
not important enough for me to invest much more time -- I already have it
amongst my utility functions and I'm extremly occupied otherwise.

Many (most?) of the active Python core developers don't read c.l.py with
any frequency. If you have a feature request, post it to the Sourceforge
bug tracker[1], preferably with a patch implementing the feature, or it's
almost certain that no-one will pick it up.

OK, I posted a feature request (it's not important enough for me to go
through the hassle of a patch if chances seem slim -- but since I already
spent some time on it I might as well give it a chance as you suggested).

[1] http://sourceforge.net/tracker/?group_id=5470

'as