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