[Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
murman at gmail.com
Sun Mar 6 16:07:57 CET 2011
Using batch files is a poor idea, IMO, because you have to explicitly
call a batch file from another, or the remainder of the caller will
not execute. Installing to System32 s also questionable, but if it's
just the launchers, it might be okay. From an installer's perspective,
it would really help if those files kept consistent component GUIDs
and had a Windows version block so it could upgrade consistently if it
changes in the future
I think Glenn Linderman hit the use cases on the head; I'm unclear why
he was against the overhead of a helper executable. The things I would
really want solutions for are these:
* double click on a script, and have it launch the right python (2 or
3, w or not)
* Probably scan for the final python[.\d]+ string and assume it's relevant.
* be able to easily invoke python to interpret a script from the command prompt
I'd be comfortable with setting associations to a set of thin
executable wrappers which examined the #! line to extract a python
version. It could fall back to the "default" version of python, which
could be defined as the highest installed on the machine, or could be
customizable by the machine's administrator. If this wrapper script
passes on all command line parameters, it could also be a reasonable
way to invoke python from the command line.
Is there a good way for the wrapper to know what versions of python
are available on Windows? Moving forward we could have a pythonx.y
installer set a value in a known registry key, and document how to
register an older python with this key. The default value of the key
could be the mechanism for setting a default python version.
I'm willing to clarify this and/or look into providing patches if it
would help; the only potentially sticky point is the contribution
agreement, but I wouldn't expect trouble with my employer.
More information about the Python-Dev