subprocess vs. proctools

[Keith Dart]

Nick Craig-Wood wrote:

> There are many ways for a program to fail (non-zero exit codes) but
> only one way for it to succeed (zero exit code).  Therefore rc should
> be 0 for success.

Exactly. And as a convenience the ExitStatus object of proctools handles 
that for you.

As a general rule, I believe Python interfaces should be more abstract 
and object-oriented. I don't think the users of my framework (myself 
included) should have to know or deal with the fact that "zero means 
good". You only need to know that if the ExitStatus object you get 
avaluates to True, it is a "good" exit.

> IMHO Shell semantics are nuts (0 is True - yeah!) - they hurt my head
> every time I have to use them ;-)

Exactly, and that is why the proctools framework hides that from the 
user-programmer.


>>>>import subprocess
>>>>subprocess.call(["sleep", "60"])
> 
> -11
> 
> # I killed the sleep process with a SEGV here from another xterm

Python> import proctools
Python> print proctools.call("sleep 60")
sleep exited by signal 11.

# same here... sent SEGV. which is easier to understand what is going on?
  (BTW, I just added a "call" function to proctools with similiar 
functionality)


> 
>>>>subprocess.call(["sleep", "asdfasdf"])
> 
> sleep: invalid time interval `asdfasdf'
> Try `sleep --help' for more information.
> 1

Python> print proctools.call("sleep asdf")
sleep: Exited abnormally with status 1.


> Signals are -ve, exit codes are +ve which seems perfect.  Exit codes
> can only be from 0..255 under linux.  Signals go from -1 to -64.

And why should my API user-programmers need to know that? That is just 
too... low-level.


>> if rc:
>>      print "exited normally"
> 
> 
> Actually I think
> 
> if rc == 0:
>      print "exited normally"
> 
> is exactly equivalent!

Yes, but requires the programmer to know that zero is good, and signals 
are negative. Again, the proctool's ExitStatus makes that more abstract 
for you (as Python interfaces should be) and provides test methods if 
you need them.

Python> rc = proctools.call("sleep asdf")
Python> rc.exited()
True
Python> rc.signalled()
False
Python> int(rc)
1
# Note that you can still get the exit value for those programs that
# return something meaningful.

Python> rc = proctools.call("sleep 60")
# send SEGV
Python> rc.signalled()
True

> I like python because I can write stuff on linux and it works on
> windows without too much effort, and in general I try not to use
> modules which don't work on both platforms.

Sorry for you. I like Python becuase it allows me to write good, solid 
programs easily and quickly. I try to make my libraries facilitate that, 
and also be easy to use for beginning Python programmers. Python on 
Linux is a powerful combination, and I cannot fathom why someone would 
choose anything less. (I would concede that Python on Darwin is also good)



-- 
                            \/ \/
                            (O O)
-- --------------------oOOo~(_)~oOOo----------------------------------------
Keith Dart <kdart at kdart.com>
public key: ID: F3D288E4 
============================================================================