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

Paul Moore pf_moore at yahoo.co.uk
Tue Aug 3 22:15:30 CEST 2004

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."

More information about the Python-Dev mailing list