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

[Marko Rauhamaa]

Stefan Zimmermann <zimmermann.code at gmail.com>:

> Calling an external command should be one of the simplest tasks in a
> high level scripting language like Python.

Actually, that's quite a tricky operation in any OS. For example, bash's
simplicity is a trap that claims a lot of victims.

Anyway, Python has os.system() that does the quick and dirty thing you
might be looking for.

> And that should not involve any OS-specific differences, unless you
> want to use some advanced process handling features which are only
> supported by some specific OS.

I can't speak for Windows, but under Linux, it gets advanced pretty
quickly (what gets inherited, how about zombies, how about signals, etc
etc).

> Meanwhile I checked Ruby and Perl regarding this feature. Both support
> it. In both langs every standard function that calls external commands
> (like Perl's exec() or system() or Ruby's exec() or system() or
> IO.popen()), whether they invoke a shell or call it directly, support
> running 'tool.bat' or 'tool.cmd' by just writing 'tool'. Python almost
> seems to be the only major scripting language which does not support
> this implicitly.

I'm not against subprocess.Popen() doing its work under Windows the way
Windows system programmers would expect. I'm against trying to force
Windows and Linux into the same mold where there are genuine
differences.

If I were a Windows developer, I'd expect Python to support something
analogous to what I'd have in C++ or C#. If pipes are natural IPC
channels under Windows, then subprocess.Popen() is probably pretty close
to its mark. However, most of the IPC facilities listed here:

   <URL: https://msdn.microsoft.com/en-us/library/windows/desktop/aa36
   5574%28v=vs.85%29.aspx>

seem to be absent in Python (clipboard, COM, data copy, DDE, file
mapping, mailslots, rpc).


Marko