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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
