[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

[Mark Hammond]

On 21/03/2011 12:27 PM, "Martin v. Löwis" wrote:
>>> I remain -1 on any proposal that uses subprocesses. It absolutely must
>>> be the launcher that is running Python. In fact, I'd call it
>>> "python.exe".
>>
>> For clarity, could you please tell us which scenarios you have in mind
>> that cause you to take that position, and why those scenarios couldn't
>> ignore the existence of the launcher and stick with doing exactly what
>> they do now (which presumably is to use python.exe directly)?
>
> I'm primarily bothered about the failure to implement TerminateProcess
> correctly. I don't actually know what use cases would be affected, other
> then saying that anything launching py.exe could be affect, in
> particular applications using ShellExecuteEx. I don't think it is
> feasible to change them all to launch something different instead; some
> may be out of our control. Potential candidates would be web servers.

This fear seems overblown to me as I doubt any such programs exist.  A 
program could not use ShellExecuteEx on an arbitrary file extension and 
hope to obtain a handle it can use to kill the process - the docs make 
it clear no handle is returned in a number of common cases and implies 
that even if you get a handle back you should not kill it (as it 
explicitly states that a single process may be the target for any number 
of such calls.)  For the same reason, you can't even wait on it unless 
you know the implementation of the associated program.

So this scenario would need to be a program which used ShellExecuteEx 
only to launch Python programs and therefore felt it could rely on the 
ability to (a) always get a handle back and (b) use TerminateProcess to 
kill it.  ISTM the likelihood of such a program existing is so low that 
it should not kill the chances of this PEP being accepted if the 
sub-process model is the only reasonable way to implement the launcher.

ie, let's say we are forced to choose between the following 3 options:

* No launcher at all (the status-quo), causing demonstrable breakage in 
Windows file associations whenever Python 2.x and Python 3.x scripts 
exist on the same box.

* An in-process launcher which caused breakage in a number of reasonably 
common scenarios for Python programmers, and such breakage could easily 
be demonstrated.

* An out-of-process launcher which caused breakage for the hypothetical 
program mentioned above, of which no instance can be found and no 
breakage actually demonstrated.

I personally would conclude that the last option is the least worst 
scenario by a wide margin.

Cheers,

Mark