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

[Dave Angel]

On 05/07/2015 06:24 AM, Chris Angelico wrote:
> On Thu, May 7, 2015 at 8:10 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Stefan Zimmermann <zimmermann.code at gmail.com>:
>>
>>> And last but not least, Popen behavior on Windows makes it difficult
>>> to write OS-independent Python code which calls external commands that
>>> are not binary by default:
>>
>> Then, write OS-dependent Python code.
>>
>> I don't think it's Python's job to pave over OS differences. Java does
>> that by not offering precious system facilities -- very painful. Python
>> is taking steps in that direction, but I hope it won't go too far.
>
> On the contrary, I think it *is* a high level language's job to pave
> over those differences. Portable C code generally has to have a
> whopping 'configure' script that digs into your hardware, OS, library,
> etc availabilities, and lets you figure out which way to do things.
> Python code shouldn't need to worry about that. You don't need to care
> whether you're on a 32-bit or 64-bit computer; you don't need to care
> whether it's an Intel chip or a RISCy one; you shouldn't have to
> concern yourself with the difference between BSD networking and
> WinSock. There'll be a handful of times when you do care, and for
> those, it's nice to have some facilities exposed; but the bulk of code
> shouldn't need to know about the platform it's running on.
>
> Java went for a philosophy of "write once, run anywhere" in its early
> days, and while that hasn't exactly been stuck to completely, it's
> still the reasoning behind the omission of certain system facilities.
> Python accepts and understands that there will be differences, so you
> can't call os.getuid() on Windows, and there are a few restrictions on
> the subprocess module if you want maximum portability, but the bulk of
> your code won't be any different on Linux, Windows, Mac OS, OS/2,
> Amiga, OS/400, Solaris, or a MicroPython board.
>
> ChrisA
>

It's a nice goal.  But these aren't OS features in Windows, they're 
shell features.  And there are several shells.  If the user has 
installed a different shell, is it Python's job to ignore it and 
simulate what cmd.exe does?

Seems to me that's what shell=True is for.  it signals Python that we're 
willing to trust the shell to do whatever magic it chooses, from adding 
extensions, to calling interpreters, to changing search order, to 
parsing the line in strange ways, to setting up temporary environment 
contexts, etc.

If there were just one shell, it might make sense to emulate its 
features.  Or it might make sense to contort its features to look like a 
Unix shell.  But with multiple possibilities, seems that's more like 
space for a 3rd party library.

-- 
DaveA