On 22/03/2011 12:04 AM, Paul Moore wrote:
I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, and for it having
command line arguments (implying direct command line usage). If it can
be used directly, there are many other scenarios that might be
impacted. Consider a service implemented using SRVANY which uses the
launcher. Stopping the service kills the launcher, leaving Python (and
the script, ie the service) running...
The intention is for the script to be used to interactively start a
Python interpreter for the convenience of the developers working
interactively. It is not intended to replace all current uses of
python.exe though, hence the different name.
Problems with things like SVRANY will be caused if those things use file
associations to implicitly launch the executable associated with .py
files - but those problems are caused by having py.exe associated with
.py files, not with the fact that py.exe can also be used to launch
python interactively. IOW, SVRANY type use-cases should continue to use
python.exe. If problems are caused due to the change in associations,
those problems would be caused even if py.exe did not have facilities
designed for interactive use.
FWIW, I do accept that if an in-process model was used there may be less
problems if use-cases like SVRANY happened to use py.exe, so should be
supported if possible. But while updating the PEP last night to
reference 64bit and 32bit considerations, this idea hit another snag. I
changed the PEP to say:
On 64bit Windows with both 32bit and 64bit implementations of the
same (major.minor) Python version installed, the 64bit version will
always be preferred. This will be true for both 32bit and 64bit
implementations of the launcher - a 32bit launcher will prefer to
execute a 64bit Python installation of the same version if
available. This is so the behaviour of the launcher can be
predicted knowing only what versions are installed on the PC and
without regard to the order in which they were installed.
I think that is sensible as needing to know the order of past
installations to predict the behaviour is undesirable. However, that
would also be impossible to achieve in an in-process model - a 32bit
launcher could not load a 64bit Python into its process, and vice-versa.
Even if the wording of the above paragraph changes, if there remains a
case where a 64bit launcher needs to load a 32bit Python or vice-versa,
the same issue will arise.
I'm starting to think the only reasonable compromise will be to use
child processes but use the win32 "job" API to arrange for Windows to
kill the child should be the parent be killed - this will need more
research and experimentation though - see
http://msdn.microsoft.com/en-us/library/ms684161%28v=vs.85%29.aspx for
an overview.
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
