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
_______________________________________________
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
