On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote:
...
... problems with creating child processes:
- applications using the debug API, PSAPI, etc. will be confused if
the action all happens in a child process. I can accept that they
have to adjust, though.
Some of these uses probably shouldn't use the launcher directly - eg,
ISAPI apps and COM objects which have a separate registration step could
register a specific python.exe - the installation script itself could by
launched by the launcher, but that script could continue to use
sys.executable to record the specific python.exe.
A side effect of this though is that if a newer version of python is
installed such that "py.exe register.py" now used the later version, the
existing registration would still use the older version until
re-registered. I think that is reasonable though.
- TerminateProcess must work correctly, and I see no way to achieve
that (i.e. terminating the parent process won't terminate the child)
I understand this concern (and meant to say this in reply to Eugene's
mail), but wonder if it isn't similar to the above - that if some
program wants to launch python and note the id of the child process so
it can terminate the child later, then python.exe could continue to be
used. OTOH, if you are terminating the process by using Process Manager
or something else to find a 'python.exe', that will continue to work and
the parent py.exe will automatically silently terminate.
That wouldn't bother me.
* There are subtle differences when Python is loaded by an executable in
the "install" directory versus by an executable that is not.
Specifically, I'm thinking about the differences in how the default
sys.path is populated.
This would need to be fixed. I.e. the launcher would have to arrange it
so it gives the illusion of having been started from the executable.
It isn't immediately obvious how that could be done though - although I
admit I haven't looked into it.
But in general, I'd be happy for py.exe to avoid CreateProcess for
CPython if that could be reasonably done and was the consensus...
Thanks,
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
