[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows
Mark Hammond
mhammond at skippinet.com.au
Mon Mar 21 01:29:34 CET 2011
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
More information about the Python-Dev
mailing list