[Python-Dev] Re: PEP 324 (process module)

[Paul Moore]

Michael Chermside <mcherm at mcherm.com> writes:

> Guido writes:
>> I believe ActiveState's Trent Mick has released something
>> along these lines.  Does your proposed API match theirs?
>
> Peter replies:
>    [...]
>> So, the chances of getting our modules API-compatible are very small.
>
> I'll note that my impression is that Peter's module is not aiming to
> be particularly innovative in terms of implementation, it's primary
> "feature" is having a decent API. And my impression is that it has
> been well received on c.l.py (for instance, I often see it recommended
> in response to newbie questions). He got a lot of input during the PEP
> process and tried to incorporate it.

Although Peter has been very receptive to feedback, he has some strong
design goals (noted in the PEP) which make the resulting module feel
too "low level" for me.

I'd love to see a function 

   process.filter(cmd, input=None)

Execute cmd (if it's a string, use the shell, if it's a list, treat as
an argv sequence) and pass it input as stdin (default, no stdin).
Return the command's stdout. If an error occurs (either in the exec,
or if the command returns a nonzero return code) raise an exception
(and capture the stderr in the exception data). This function should
deal with deadlock issues.

I don't know of *any* process module that makes this "expect it to
work" model any easier. And Peter's design constraint of avoiding the
shell actively hurts here (although his interact() function is
specifically there to avoid the deadlock issues that could otherwise
occur with a naive attempt to implement this).

It's possible that I could implement this function on top of Trent's
module. Must try...

Paul.
-- 
"Bother," said the Borg, "We've assimilated Pooh."