subprocess vs. proctools

[Keith Dart]

Donn Cave wrote:
> Keith Dart <kdart at 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 <kdart at kdart.com>
public key: ID: F3D288E4
============================================================================