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

[Mark Hammond]

On 20/03/2011 5:49 AM, "Martin v. Löwis" wrote:
>> * Is this really PEP material, or will turning the PEP into a regular
>> spec be suitable?
>
> It's PEP material if it is contentious, which I believe it is.

Of course it is - this is python-dev <wink>.

> I, for example, will find issues with it if the implementation uses
> CreateProcess at some point - the launcher should IMO run Python
> directly, rather than creating a new process. This, in turn, will
> probably mean that you cannot actually implement the PEP in Python.

Out of curiosity, what is your objection to having the child process?  I 
guess it must be the system resources needed for the parent process 
while it waits for the child to terminate so the exit code can be 
reflected correctly "up stream"?

I would have 3 main problems with dynamically loading Python into the 
launcher process:

* It may be difficult or impossible to do for implementations other than 
CPython.

* 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.

* The registry doesn't currently tell us exactly where pythonxx.dll can 
be located, but does tell is where python.exe is.  Thus things would get 
a little more complex as we go snooping for the location of the DLL.

Note that these are almost certainly surmountable, but I wonder if the 
benefits outweigh the costs.

>> * If it is a PEP, is it "Standards Track" or "Informational"?
>
> If you are proposing to change the CPython code base (which I think you
> should), it's standards track. If you are talking about a tool provided
> by you on PyPI, you actually don't need to discuss it with anybody.

Thanks - "Standards Track" it is then :)  FWIW, I have no interest in 
making this a stand-alone project or distribution.  If there is 
agreement that this shouldn't be part of Python itself (which may well 
be a reasonable decision to make), I'll let the idea die.

>
>> * Does the functionality described strike the right balance between
>> simplicity and usefulness?
>
> It leaves a number of issues still open, so it's hard to tell yet.
> For example, the 32-bit vs. 64-bit issue should be resolved (which I
> think comes down to having 4 binaries).

This is an interesting one and one which I don't have a firm opinion 
about - but the soft opinion I have is something along the lines of "the 
functionality should not be dictated by the bittedness of the launcher 
itself".  IOW, if we decide that a 64bit implementation of Python should 
be chosen over a 32bit implementation of the exact same version, this 
should be done by both the 32bit and 64bit launchers.

Of course, I welcome more thoughts on this and could be easily swayed.

> Plus, it should talk about
> installation of multiple copies of the same Python version, e.g.
> from ActivePython, EPD, etc.

Good point - this is something I haven't considered at all.  Any 
thoughts on this from anyone?

> Notice that the PEP doesn't talk about file associations yet (but it
> should).

Actually, it does say '...the "console" version of the launcher should 
be associated with .py files and the "windows" version associated with 
.pyw files.'

What extra level of detail do you feel is necessary?

> I'm fine with the strategy, but I feel that the devil's in the detail.

Indeed!  But general approval for the strategy is an encouraging first 
step :)

Thanks!

Mark