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

[Mark Hammond]

On 21/03/2011 11:10 AM, "Martin v. Löwis" wrote:
> Am 21.03.2011 00:52, schrieb Mark Hammond:
>> On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
>>>> The above raises an interesting question - if the launcher executed
>>>> Python in-process, what would sys.executable be?  I can imagine there
>>>> are few scenarios where it would be desirable to have it refer to the
>>>> launcher and a number of scenarios where it would be undesirable and
>>>> possibly break existing scripts.
>>>
>>> Interesting question. What is it in COM and ISAPI applications?
>>
>> ISAPI isn't a good example - that uses DLLs.
>
> Actually, this is precisely the example i was looking at.
>
>> For COM objects hosted in
>> a .exe it will be pythonw.exe.  For Windows services it will be
>> pythonservice.exe (which is part of pywin32 and is located simply by
>> assuming it is next to win32service.pyd)
>>
>> Regardless, I don't think they are very likely to break - my concern is
>> more for "normal" scripts which construct a child process cmdline/argv
>> using sys.executable...
>
> If we find out how other cases of just loading the DLL deal with
> sys.executable, it may help us in guiding how it should be set in the
> launcher.

I guess it is all about context; in an ISAPI application or in a COM 
object implemented in a DLL, sys.executable will be the name of the host 
process (which is determined in PC/getpathp.c by calling 
GetModuleFileName with a NULL handle).  People writing ISAPI apps or COM 
objects are likely to understand the implications of them existing in 
some process which isn't python[w].exe so will ignore sys.executable and 
use some other technique to locate a python[w].exe if they need it.

"Normal" scripts are less likely to do so - a code search at google for 
sys.executable shows it used in ways which would possibly break if 
sys.executable referred to a launcher and the launcher didn't use the 
"current" version of Python as the default.  Often these are in tests or 
setup.py, but we would need to avoid any such breakage.

[Which isn't to suggest we can't avoid such breakage with an "in-process 
launcher" - it just isn't immediately clear how we would do so]

Cheers,

Mark