Python vs. Perl

[Michael McGarry]

Hi,

I am just starting to use Python. Does Python have all the regular
expression features of Perl?

Is Python missing any features available in Perl?

Thanks,

Michael

[Roy Smith]

Michael McGarry <re**********@nospam.org> wrote:

I am just starting to use Python. Does Python have all the regular
expression features of Perl?
I can't vouch for "all", but the Python reference manual for the "re"
module (http://docs.python.org/lib/module-re.html) says, "This module
provides regular expression matching operations similar to those found
in Perl".
Is Python missing any features available in Perl?

Are you talking specifically about regex, or about the language in
general? If the latter, then the answer is "Yes, and this is a Good
Thing". If you meant the former, then I suspect the answer is that
anything you can do with a Perl regex you can also do with a Python
regex. I'm a pretty heavy regex user, and I've never found anything I
wanted to do which I was unable to.

The biggest difference between regex support in Perl and Python is that
Perl has regex syntax built into the core language, while Python does it
with a module that you have to import and then call functions inside
that module. Which you like better is a matter of personal opinion.
Like most Perl-Python feature comparisons, the Perl version usually ends
up more compact, but the Python version ends up easier to understand.

[Christopher De Vries]

Roy Smith already touched on regular expressions, but as far as
features go, I would say that the real difference between python and
perl is not in the features, but in the philosophy. It seems to me that
any program you can write in python could also be written in perl. What
it comes down to for me was which language most fit the way I tend to
think. I decided python was that language, and I found everything very
intuitive. I have a good friend who thinks in perl and is very
productive using it.

Other people might disagree, but when I was looking at perl and python
I borrowed recent copies of "Learning Perl" and "Learning Python" from
the O'Reilly series and after reading each, decided I preferred python.
You can find out about most of the features in those books.

Chris

[loritsch]

Christopher De Vries wrote:

Roy Smith already touched on regular expressions, but as far as
features go, I would say that the real difference between python and
perl is not in the features, but in the philosophy.

To help aid in this discussion, the following Python and Perl
philosophy links might be useful:
http://c2.com/cgi/wiki?PythonPhilosophy
http://www.maths.adelaide.edu.au/~cm...ntro/x175.html

Now, so that I don't start another Python vs. Perl flamewar, I'd like
to inform everyone that I'm about to make a few generalizations based
on my experience. As should be understood implicitly, one man's
experience is not the experience of everyone...

As a user of both languages, I've found that what Perl and Python
programmers have in common is that they were looking for a better tool
when they stumbled across their language of choice... After all, one
can be productive in both languages.

What I've also noticed that people who use Perl tended to start using
it as a way to make either C or shell scripting tasks easier (after
all, this is Perl's original intended audience). Many of these
developers have gone on to use Perl for bigger and better things, but
without a lot of discipline (use strict, and a lot of work with the
Exporter), Perl doesn't scale very well to large projects. My belief
is that Perl's strength (TMTOWTDI) is also it's greatest weakness.

I've also noticed that Python programmers tend to be a more diverse
lot. While Guido originally intended Python to be a second language
for C/C++ developers, it is also quite useful as a first language.
Python's philosophy is more that there should a clear understandable
way to do things, and that readability counts. That is not to say you
can't perform tasks in multiple ways, it is just to say that Python
doesn't believe in TMTOWTDI as Perl does.

So the bottom line is this. In choosing Perl or Python, the real
difference should be your mindset, and what you intend to use it for.
If you want a multiparadigm programming language that offers wonderful
OO support, is easy to learn, and in which you will naturally write
maintainable code, choose Python.

On the other hand, if you are looking for a language to text-processing
and to perform short quick shell scripting like tasks, choose Perl.
While both languages can be used to perform both sets of tasks, my
belief is that one should pair a language and a task by strengths
rather than what can be done in each language.
I hope this helps!

Michael Loritsch

[Michael McGarry]

lo******@gmail.com wrote:

Christopher De Vries wrote:

Roy Smith already touched on regular expressions, but as far as
features go, I would say that the real difference between python and
perl is not in the features, but in the philosophy.

To help aid in this discussion, the following Python and Perl
philosophy links might be useful:
http://c2.com/cgi/wiki?PythonPhilosophy
http://www.maths.adelaide.edu.au/~cm...ntro/x175.html

Now, so that I don't start another Python vs. Perl flamewar, I'd like
to inform everyone that I'm about to make a few generalizations based
on my experience. As should be understood implicitly, one man's
experience is not the experience of everyone...

As a user of both languages, I've found that what Perl and Python
programmers have in common is that they were looking for a better tool
when they stumbled across their language of choice... After all, one
can be productive in both languages.

What I've also noticed that people who use Perl tended to start using
it as a way to make either C or shell scripting tasks easier (after
all, this is Perl's original intended audience). Many of these
developers have gone on to use Perl for bigger and better things, but
without a lot of discipline (use strict, and a lot of work with the
Exporter), Perl doesn't scale very well to large projects. My belief
is that Perl's strength (TMTOWTDI) is also it's greatest weakness.

I've also noticed that Python programmers tend to be a more diverse
lot. While Guido originally intended Python to be a second language
for C/C++ developers, it is also quite useful as a first language.
Python's philosophy is more that there should a clear understandable
way to do things, and that readability counts. That is not to say you
can't perform tasks in multiple ways, it is just to say that Python
doesn't believe in TMTOWTDI as Perl does.

So the bottom line is this. In choosing Perl or Python, the real
difference should be your mindset, and what you intend to use it for.
If you want a multiparadigm programming language that offers wonderful
OO support, is easy to learn, and in which you will naturally write
maintainable code, choose Python.

On the other hand, if you are looking for a language to text-processing
and to perform short quick shell scripting like tasks, choose Perl.
While both languages can be used to perform both sets of tasks, my
belief is that one should pair a language and a task by strengths
rather than what can be done in each language.
I hope this helps!

Michael Loritsch

Thank you all for your input. Please feel free to keep this discussion
going.

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

I welcome any opinions on this.

[Christos TZOTZIOY Georgiou]

On Sat, 11 Dec 2004 15:10:04 -0700, rumours say that Michael McGarry
<re**********@nospam.org> might have written:

Thank you all for your input. Please feel free to keep this discussion
going.

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

I welcome any opinions on this.

I don't know if my opinion will help, but I know if you follow my
advice, it will be enlightening :)

Both languages cover all of your requirements. So read as much
documentation needed to write some simple programs as examples doing
similar tasks to the one you want in *both* languages. Test them that
they work. Then forget about your problems. Go to an island. Dream.
Relax. Come back without explanations six months later, and if they
take you back in the same company, read *both* of your example programs.
You'll know then which language to select (I would select the language
of the island natives, but that's another story :)
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...

[Timo Virkkala]

Christos TZOTZIOY Georgiou wrote:

Both languages cover all of your requirements. So read as much
documentation needed to write some simple programs as examples doing
similar tasks to the one you want in *both* languages. Test them that
they work. Then forget about your problems. Go to an island. Dream.
Relax. Come back without explanations six months later, and if they
take you back in the same company, read *both* of your example programs.
You'll know then which language to select (I would select the language
of the island natives, but that's another story :)

That's unfair! That approach leads to Python every time!

Oh wait, that was the purpose.. :)

--
Timo Virkkala

[Jon Perez]

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

For GUI development and front end, Python most likely has better
facilities than Perl, but still leaves a lot to be desired (after
getting a taste of Delphi 3rd party VCL components, all other RAD
environments pale in comparison).

[Ian Bicking]

Jon Perez wrote:

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front end
code for my simulations in C. I want a language that can support SQL,
Sockets, File I/O, and shell interaction.

In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

Shell interaction (or rather, external process interaction) is a lot
better with Python 2.4's subprocess module. Better or worse than Perl?
I'm not sure; generally I'd guess better, as it avoids the shell with
all the shell's issues, and provides a more controlled programmatic way
of interacting with subprocesses. OTOH, Perl might have perfectly good
modules for doing the same thing. I can only say it's been missing for
a while in Python, and it's good to see this done right.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[Keith Dart]

Ian Bicking wrote:

Jon Perez wrote:

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front
end code for my simulations in C. I want a language that can support
SQL, Sockets, File I/O, and shell interaction.

In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

Shell interaction (or rather, external process interaction) is a lot
better with Python 2.4's subprocess module. Better or worse than Perl?
I'm not sure; generally I'd guess better, as it avoids the shell with
all the shell's issues, and provides a more controlled programmatic way
of interacting with subprocesses. OTOH, Perl might have perfectly good
modules for doing the same thing. I can only say it's been missing for
a while in Python, and it's good to see this done right.

Yow, I must not get picked up in Google enough. ;-) The "proctools"
module in the pyNMS package <http://sourceforge.net/projects/pynms/> has
been around for years. I use it all the time for shell-like stuff. There
is also an "expect" module, and the "termtools" module. If you need a
more complete process spawning and controlling framework then use pyNMS.
It can "juggle" multiple processes, reaps child status (no
zombies), operates asynchronously (The ProcManager object is a SIGCHLD
handler), and works with pty's and pipes. It also offers a "thread-like"
interface for Python subprocesses (uses fork). Can leave some fd's open
that you specify, can run the subprocess as a different user, and more...
Check it out.

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

[Keith Dart]

Keith Dart wrote:

Ian Bicking wrote:

Jon Perez wrote:

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front
end code for my simulations in C. I want a language that can support
SQL, Sockets, File I/O, and shell interaction.


In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

Shell interaction (or rather, external process interaction) is a lot
better with Python 2.4's subprocess module. Better or worse than
Perl? I'm not sure; generally I'd guess better, as it avoids the
shell with all the shell's issues, and provides a more controlled
programmatic way of interacting with subprocesses. OTOH, Perl might
have perfectly good modules for doing the same thing. I can only say
it's been missing for a while in Python, and it's good to see this
done right.

Yow, I must not get picked up in Google enough. ;-) The "proctools"
module in the pyNMS package <http://sourceforge.net/projects/pynms/> has
been around for years. I use it all the time for shell-like stuff. There
is also an "expect" module, and the "termtools" module. If you need a
more complete process spawning and controlling framework then use pyNMS.
It can "juggle" multiple processes, reaps child status (no
zombies), operates asynchronously (The ProcManager object is a SIGCHLD
handler), and works with pty's and pipes. It also offers a "thread-like"
interface for Python subprocesses (uses fork). Can leave some fd's open
that you specify, can run the subprocess as a different user, and more...
Check it out.

Oh, I forgot to mention that it also has a more user- and
programmer-friendly ExitStatus object that processess can return. This
is directly testable in Python:

proc = proctools.spawn("somecommand")
exitstatus = proc.wait()

if exitstatus:
print "good result (errorlevel of zero)"
else:
print exitstatus # prints message with exit value


--
\/ \/
(O O)
-- --------------------oOOo~(_)~oOOo----------------------------------------
Keith Dart <kd***@kdart.com>
vcard: <http://www.kdart.com/~kdart/kdart.vcf>
public key: ID: F3D288E4 URL: <http://www.kdart.com/~kdart/public.key>
================================================== ==========================

[Keith Dart]

Keith Dart wrote:

Ian Bicking wrote:

Jon Perez wrote:

Michael McGarry wrote:

I intend to use a scripting language for GUI development and front
end code for my simulations in C. I want a language that can support
SQL, Sockets, File I/O, and shell interaction.


In my experience, Python is definitely much more suitable than Perl
for the first four areas mentioned in the last sentence. For the
last area, I'm not sure, but Python's capabilities in this area are
also quite good.

Shell interaction (or rather, external process interaction) is a lot
better with Python 2.4's subprocess module. Better or worse than
Perl? I'm not sure; generally I'd guess better, as it avoids the
shell with all the shell's issues, and provides a more controlled
programmatic way of interacting with subprocesses. OTOH, Perl might
have perfectly good modules for doing the same thing. I can only say
it's been missing for a while in Python, and it's good to see this
done right.

Yow, I must not get picked up in Google enough. ;-) The "proctools"
module in the pyNMS package <http://sourceforge.net/projects/pynms/> has
been around for years. I use it all the time for shell-like stuff. There
is also an "expect" module, and the "termtools" module. If you need a
more complete process spawning and controlling framework then use pyNMS.
It can "juggle" multiple processes, reaps child status (no
zombies), operates asynchronously (The ProcManager object is a SIGCHLD
handler), and works with pty's and pipes. It also offers a "thread-like"
interface for Python subprocesses (uses fork). Can leave some fd's open
that you specify, can run the subprocess as a different user, and more...
Check it out.

Oh, I forgot to mention that it also has a more user- and
programmer-friendly ExitStatus object that processess can return. This
is directly testable in Python:

proc = proctools.spawn("somecommand")
exitstatus = proc.wait()

if exitstatus:
print "good result (errorlevel of zero)"
else:
print exitstatus # prints message with exit value


--
\/ \/
(O O)
-- --------------------oOOo~(_)~oOOo----------------------------------------
Keith Dart <kd***@kdart.com>
vcard: <http://www.kdart.com/~kdart/kdart.vcf>
public key: ID: F3D288E4 URL: <http://www.kdart.com/~kdart/public.key>
================================================== ==========================

[Nick Craig-Wood]

Keith Dart <kd***@kdart.com> wrote:

Oh, I forgot to mention that it also has a more user- and
programmer-friendly ExitStatus object that processess can return. This
is directly testable in Python:

proc = proctools.spawn("somecommand")
exitstatus = proc.wait()

if exitstatus:
print "good result (errorlevel of zero)"
else:
print exitstatus # prints message with exit value

This sounds rather like the new subprocess module...

import subprocess
rc = subprocess.call(["ls", "-l"]) total 381896
-rw-r--r-- 1 ncw ncw 1542 Oct 12 17:55 1
[snip]
-rw-r--r-- 1 ncw ncw 713 Nov 16 08:18 z~ print rc

0

IMHO the new subprocess module is a very well thought out interface...

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[Keith Dart]

Nick Craig-Wood wrote:

Keith Dart <kd***@kdart.com> wrote:

Oh, I forgot to mention that it also has a more user- and
programmer-friendly ExitStatus object that processess can return. This
is directly testable in Python:

proc = proctools.spawn("somecommand")
exitstatus = proc.wait()

if exitstatus:
print "good result (errorlevel of zero)"
else:
print exitstatus # prints message with exit value

This sounds rather like the new subprocess module...

import subprocess
rc = subprocess.call(["ls", "-l"])
total 381896
-rw-r--r-- 1 ncw ncw 1542 Oct 12 17:55 1
[snip]
-rw-r--r-- 1 ncw ncw 713 Nov 16 08:18 z~
print rc

0

But this evaluates to False in Python, but True in a shell. It also
requires an extra check for normal exit, or exit by a signal. The
proctools ExitStatus object avaluates to True only on a normal exit,
period. Thus it follows a shell semantics for clarity. You cannot do
this with the subprocess module:

if rc:
print "exited normally"
But in proctools, the exitstatus is an object that evaluates True only
for normal exit.

import proctools
proc = proctools.spawnpipe("ls -l")
print proc.read()
....
print proc.exitstatus
ls: Exited normally.
proc = proctools.spawnpipe("ls -l xx")
print proc.read()
'ls: xx: No such file or directory\n'

print proc.exitstatus
ls: Exited abnormally with status 1.

if proc.exitstatus:
print "returned normally"
But you can get the integer return value, if you want it, like this:
int(proc.exitstatus)

or query it with methods returning booleans:

exitstatus.exited()
exitstatus.signalled()
exitstatus.stopped()

Also, proctools lets you use a pty, if you choose. Not every program
works well from a pipe.

IMHO the new subprocess module is a very well thought out interface...

The proctools Process object presents a file-like object to the rest of
Python, which makes a process polymorhic with any other file, pipe or
socket object. It has the usual read, write, readline, and readlines
methods. It can also be made non-blocking, and you can have many open at
once. In addition, there are special methods for controlling the
sub-process: You can kill it, stop it, re-start it, clone it, wait on
it, and get stats from it. The stat() method returns a ProcStat object,
which has attributes like what you get from the 'ps' program. Need to
know the process's RSS? No problem. It also supports logging to a log
file, and on-exit callback for persistent process requirements.

You always invoke the spawn* functions with a string. This is parsed by
a shell-like parser (the shparser module that comes with it), but no
/bin/sh is invoked. The parser can handle single and double quotes, and
backslash escapes.

Alas, one thing the proctools module does not do well yet is create a
pipeline. I have plans to fix that.

It does not work with MS Windows, but can work with cygwin on Windows.
Whew... and I have not even covered the ProcessManager object...

--
\/ \/
(O O)
-- --------------------oOOo~(_)~oOOo----------------------------------------
Keith Dart <kd***@kdart.com>
vcard: <http://www.kdart.com/~kdart/kdart.vcf>
public key: ID: F3D288E4 URL: <http://www.kdart.com/~kdart/public.key>
================================================== ==========================

[Donn Cave]

Keith Dart <kd***@kdart.com> wrote:
|>> Oh, I forgot to mention that it also has a more user- and
|>> programmer-friendly ExitStatus object that processess can return. This
|>> is directly testable in Python:
|>>
|>> proc = proctools.spawn("somecommand")
|>> exitstatus = proc.wait()
|>>
|>> if exitstatus:
|>> print "good result (errorlevel of zero)"
|>> else:
|>> print exitstatus # prints message with exit value

This is indeed how the shell works, though the actual failure value
is rarely of any interest. It's also in a more general sense how
C works - whether errors turn out to be "true" or "false", in either
case you test for that status (or you don't.)

Python doesn't work that way, there is normally no such thing as
an error return. An idiomatic Python interface would be

try:
proc = proctools.spawn(command)
proc.wait()
print 'good result'
except proctools.error, ev:
print >> sys.stderr, '%s: %s' % (proc.name, ev.text)

[... list of features ...]

| You always invoke the spawn* functions with a string. This is parsed by
| a shell-like parser (the shparser module that comes with it), but no
| /bin/sh is invoked. The parser can handle single and double quotes, and
| backslash escapes.

It was sounding good up to here. A lot depends on the quality of
the parser, but it's so easy to support a list of arguments that
gets passed unmodified to execve(), and such an obvious win in the
common case where the command parameters are already separate values,
that an interface where you "always" have to encode them in a string
to be submitted to your parser seems to be ignoring the progress that
os.spawnv and popen2.Popen3 made on this. Of course you don't need
to repeat their blunders either and accept either string or list of
strings in the same parameter, which makes for kind of a shabby API,
but maybe a keyword parameter or a separate function would make sense.

Donn Cave, do**@u.washington.edu

[Keith Dart]

Donn Cave wrote:

Keith Dart <kd***@kdart.com> wrote:
|>> if exitstatus:
|>> print "good result (errorlevel of zero)"
|>> else:
|>> print exitstatus # prints message with exit value

This is indeed how the shell works, though the actual failure value
is rarely of any interest. It's also in a more general sense how
C works - whether errors turn out to be "true" or "false", in either
case you test for that status (or you don't.)

Python doesn't work that way, there is normally no such thing as
an error return. An idiomatic Python interface would be

try:
proc = proctools.spawn(command)
proc.wait()
print 'good result'
except proctools.error, ev:
print >> sys.stderr, '%s: %s' % (proc.name, ev.text)

Your first statement is exactly right. One does not always care about
the return value of an external process. And some programs still return
an undefined value, even when successful. Therefore, I don't want to
always have to wrap a call to an external program in a try..except
block. Thus, it returns an ExitStatus object that you can easily test
true-false with as in a shell, or get the actual value if you need it.
Otherwise, just ignore it.

[... list of features ...]

| You always invoke the spawn* functions with a string. This is parsed by
| a shell-like parser (the shparser module that comes with it), but no
| /bin/sh is invoked. The parser can handle single and double quotes, and
| backslash escapes.

It was sounding good up to here. A lot depends on the quality of
the parser, but it's so easy to support a list of arguments that
gets passed unmodified to execve(), and such an obvious win in the
common case where the command parameters are already separate values,
that an interface where you "always" have to encode them in a string
to be submitted to your parser seems to be ignoring the progress that
os.spawnv and popen2.Popen3 made on this. Of course you don't need
to repeat their blunders either and accept either string or list of
strings in the same parameter, which makes for kind of a shabby API,
but maybe a keyword parameter or a separate function would make sense.

Actually, an earlier version of proctools did take a list. However,
after much usage I realized that in most cases what I got was a string
to begin with. Either from user input or read from a file. I also found
it easier to construct command-lines using the string-mod operator,
substituting various attributes into option-value pairs in arbitrary
ways. I was having to split/parse a string so often I decided to just
make the Process object parse it itself. The shparser module has been
perfectly adequate for this, and you can pass to the Process object
pretty much the same string as you would to a real shell (thus making it
easier to use for *nix people). I could add a list-input check, but
likely I would never use it.

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

[Nick Craig-Wood]

Keith Dart <kd***@kdart.com> wrote:

Nick Craig-Wood wrote:

This sounds rather like the new subprocess module...

>import subprocess
>rc = subprocess.call(["ls", "-l"])
total 381896
-rw-r--r-- 1 ncw ncw 1542 Oct 12 17:55 1
[snip]
-rw-r--r-- 1 ncw ncw 713 Nov 16 08:18 z~

>print rc

0

But this evaluates to False in Python, but True in a shell.

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.

IMHO Shell semantics are nuts (0 is True - yeah!) - they hurt my head
every time I have to use them ;-)
It also requires an extra check for normal exit, or exit by a
signal.

import subprocess
subprocess.call(["sleep", "60"]) -11 # I killed the sleep process with a SEGV here from another xterm
subprocess.call(["sleep", "asdfasdf"]) sleep: invalid time interval `asdfasdf'
Try `sleep --help' for more information.
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.
The proctools ExitStatus object avaluates to True only on a normal
exit, period. Thus it follows a shell semantics for clarity. You
cannot do this with the subprocess module:

if rc:
print "exited normally"
Actually I think

if rc == 0:
print "exited normally"

is exactly equivalent!

[snip] It does not work with MS Windows

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.

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[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 <kd***@kdart.com>
public key: ID: F3D288E4
================================================== ==========================