RetroSearch Browse

Wed Jan 7 10:21:15 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-January/041772.html

> This PEP looks fantastic to me; I've often wanted a better set of
> primitives for working with external processes, and your PEP has just
> about everything I've ever wanted.

Great :-)

> I do have some minor nits to pick, though:
> 
> - The preexec_args argument is extraneous considering how easy it is to
> use a lambda construct to bind arguments to a function.  Consider:
> 
>   Popen(..., preexec_fn=foo, preexec_args=(bar,baz))
> 
> vs.
> 
>   Popen(..., preexec_fn=lambda: foo(bar,baz))

Nice. The only drawback with this approach that I can think of right now
is that this will be hard for newbies to understand, but if we give a few
examples in the doc this is probably not a problem.

I'll make this change, unless I hear protests. 

> - Rather than passing argv0 as a named argument, what about passing in
> the program to execute instead?  It would simplify code like this:
> 
>   Popen(child_program, *child_args[1:], argv0=child_args[0])
> 
> into this
> 
>   Popen(*child_args, program=child_program)
> 
> Of course I'm not suggesting you change the default behavior of taking
> argv0 *and* the program to execute from the first positional argument.

I don't understand exactly what you mean here; could you provide a working 
example?

> - The defaults for close_fds and universal_newlines should be False
> rather than 0; this would make it clear from reading the synopsis that
> these arguments are boolean-valued.

Yes, I've fixed this now. 

> - The poll() method and returncode attribute aren't both needed. I like
> returncode's semantics better since it gives more information and it
> avoids using -1 as a magic number.

Well, as I described in another mail, it's actually a big advantage to 
provide both a returncode attribute and an unmodified status value, since 
it's makes it easy to migrate from the "old" API. Perhaps we'll need to 
make some changes to the poll() method wrt Windows, though. 

> - Rather than raising a PopenException for incorrect arguments, I would
> think that raising ValueError or TypeError would be more in line with
> users' expectations.

Sounds good to me. Anyone else has comments? 

> - How does this communicate() method interact with I/O redirection?

Now I'm lost again. Which kind of redirection are you thinking about?

/Peter

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-January/041772.html below:

[Python-Dev] PEP 324: popen5 - New POSIX process module