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

[Chris Angelico]

On Fri, May 8, 2015 at 1:24 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> 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.

In that case, what you should do is devise an alternative language
that compiles as a thin layer over C. Have a simple translation script
that turns your code into actual C, then passes it along for
compilation. You could add whatever Python-like features you want
(memory management, maybe), but still be executing as C code. But you
don't want a high level language, if your greatest goal is "closely
mirror 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.

Ah, but that's a completely different thing. If you're working with a
child that isn't written in Python, then you're not working at the
level of the multiprocessing library - you're working with "I need to
give this something on its stdin and get the result back from its
stdout". For that, yes, you need something a bit more concrete; but
now it's become part of the API for that child process, whereas the
example I was giving was about the multiprocessing library, where it's
part of the implementation.

ChrisA