[Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

Glenn Linderman v+python at g.nevcal.com
Mon Mar 7 05:30:12 CET 2011


On 3/6/2011 7:07 AM, Michael Urman wrote:
> 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.

I'm only against the overhead of a helper written in Python, since it 
would have to launch Python (some explicit version) to run the helper 
script, and then launch the "right" version of Python to execute the 
real script.  You mention a thin executable wrapper, and I have no 
problem with the overhead of that, probably.

Seems that the PEP addresses two sub problems on Unix created by the 
coexistence of multiple incompatible major versions of Python:

(1) how to invoke the right version of the interactive Python from the 
command line, and
(2) how to specify the right version of Python inside Python scripts.

One solution solves both problems on Unix... the declaration that 
/usr/bin/python (generally on the PATH and invocable from the shell as  
python) may be an installation dependent version, and the creation of 
appropriate version specific links and/or binaries for specific major 
and/or minor versions, to be used either from the command line or the #! 
line of scripts.

For Windows, it is true at present that neither of the above problems 
has a solution:
(1) a fully qualified installation path name must be used to invoke any 
version of Python, since it is not on the PATH
(2) Only the last installed version of Python will be invoked by 
launching a Python script name something-or-another.py

Hence, omitting Windows behaviors from the PEP leaves Windows without a 
solution for either problem, no worse off than it was before, but 
neither is it better off.

If the PEP wants to address (1) interactive launching from the command 
line on Windows, that could be done by placing a batch file in System32; 
providing versioned symlinks in installed on a file system that supports 
them, or providing versioned binaries on a file system that doesn't 
support symlinks, either in System32, or by adding the Python 
installation directory to the PATH.  For interactive use, most of these 
solutions are roughly equivalent in function.

Since Windows does not use a #! line, then the solutions for (2) must be 
different.  The ones that I can think of are:

(A) declare the Python version in the name of the script file.  By doing 
so in the extension, additional Windows associations could be created to 
launch different versions of Python.  Switching versions would be as 
simple as renaming the file, changing the extension to include a 
different version.  However, various tools would have to learn about 
additional extensions that mean Python (syntax directed editors, etc.)  
And it would be hard to have a script in a module, unless the importer 
recognized all those extensions too.  So this "solution" has ripple 
effects that make it unattractive, although it is simple to implement 
the basic feature.

(B) declare the Python version in the content of the script file.  This 
cures most of the ripple effects of the above, but requires a "launcher" 
or "wrapper" program to be designed, implemented, and installed.  There 
are a variety of subsolutions for different ways of declaring the version.

(B1) Use the Unix #! line, and attempt to parse the version from it.  
This assumes there is a Unix #! line, note that Windows-only scripts 
wouldn't need them in the first place.  Looking at and interpreting the 
Unix #! line, and translating it into an invocation of Python on Windows 
is clever and doable, but very tightly tied to Python.

(B2) Use a second #! line, and attempt to parse a whole command from it, 
using Windows pathname syntax.  This is attractive for cross-platform 
script, and builds on the Unix #! line which is well-understood by Unix 
and cross-platform developers.  Again, Windows-only scripts wouldn't 
need a Unix #! line, but if this solution uses a second one, then the 
first must be created, possibly empty.  Also, if there are parameters 
the script needs that only apply to one platform, they could be placed 
in the appropriate platform's #! line.

(B3) Invent a variant syntax for #! -- perhaps #@.  Since it is 
different than #!, it could be on the first line, if no Unix #! line is 
needed, but if not found on the first line, the second line would be 
examined, to allow #! on the first line for a cross-platform script.  
Same costs/benefits as (B2).

(B4) As a variation on (B2) or (B3), the declaration of the version 
would not have to be a command line format... it could be   "#@ Version 
3.2", as it is purely up to the launcher/wrapper program to interpret 
it.  This complicates the wrapper script, as it would have to examine 
the registry to find the particular location of Python, and tightly 
binds it to Python usage only.


I like (B3) best, now that I've thought of it, although I implemented a 
form of (B2) in a private copy of http.server so I could have a 
cross-platform CGI script.

(B2) and (B3) also allow the wrapper to be configured to work for 
similar things for other scripting languages, which also have 
cross-platform problems similar to Python.  All the user would have to 
do is put the extra #!/#@ line in, and associate that extension with the 
wrapper.

By default, for Python, the wrapper would get associated only with .py 
files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/5ec15b80/attachment.html>


More information about the Python-Dev mailing list