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()
TrueI 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 <[EMAIL PROTECTED]>
public key: ID: F3D288E4 ============================================================================
--
http://mail.python.org/mailman/listinfo/python-list
