> * 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. 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. Others may find issues if the PEP proposes to change the standard association for .py (and also issues if it doesn't). > * 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. > * 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). Plus, it should talk about installation of multiple copies of the same Python version, e.g. from ActivePython, EPD, etc. > * Does the strategy have general support from Martin, who as the person > making Python distributions would need to be involved in at least some > aspects of it (specifically, having the installer MSI install the > launcher and update the file associations to reference it). Notice that the PEP doesn't talk about file associations yet (but it should). I'm fine with the strategy, but I feel that the devil's in the detail. Regards, Martin _______________________________________________ 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
