PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> What's the best way to farm work off to a bunch of processes and have
> them communicate their results back? You use the subprocess module,
> and then it doesn't matter whether they use Unix sockets, named pipes,
> physical files on the disk, or miniature nuclear explosions, they'll
> communicate back just fine. And when someone develops a new platform
> that uses nuclear fusion instead of fission for interprocess
> communication, Python's standard library gets enhanced, and your code
> instantly works - you don't have to specifically handle the new case.
>
> That's Python's job. Abstracting away all those differences so you
> don't have to look at them.

That's the difference between our opinions: you want Python to work the
same on different OS's. I want Python's system programming facilities to
closely mirror those of C.

Take your example of subprocess.Popen. It may be essential to know that
the communication channel is a pipe with standard pipe semantics. The
child program might not be written in Python, after all. In fact, at
system design level you shouldn't care what language you use as long as
the communication interfaces are specified.

Java is lousy at system programming (while excellent in many other
respects). It has traditionally tried to avoid the associated issues by
effectively mandating that all parts of a system be written in Java.
Gladly, Python hasn't (yet) made the same mistake.


Marko