[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

[Mark Hammond]

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