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

[Glenn Linderman]

On 3/4/2011 5:21 AM, Nick Coghlan wrote:
> On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> Should any of this also apply to Mac OS X and Windows?
> Any platform that considers itself "unix-like" in this context can
> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
> aspects of OS X). The main point of the PEP is to get a consensus
> recommendation out of python-dev as to the best way forward (and I
> think Kerrick did a good job of summarising the position that has been
> expressed in this thread).
>
> More generally, Windows and Mac OS X developers seem to be happier
> with the idea of bundling a Python interpreter inside the application
> than traditional *nix style platforms. This is a PITA for the system
> maintainer when it comes time to handle security vulnerabilites, but
> certainly more convenient when upgrading the default Python install.

Probably because Windows itself is so bloated -- so what is the problem 
with a few extra copies of Python, one per application?

I'm a Windows developer by necessity, rather than choice, but I still 
say ICK to bundling a Python inside my 50-100K Python scripts... bloats 
them to several MB each.


>> Note that we *do* have alternative distributors [1] of Python for these
>> platforms who may wish to follow any recommendations we have for 2.7, even
>> if we don't modify those installers for our own distributions.
> The really tricky part on Windows is handling file associations. I
> think we're just doomed on that front, unless we want to start
> supporting separate .py2 and .py3 extensions (and adding *that* in a
> maintenance release would be a far cry from just adding another
> symlink).

Supporting .py2 and .py3 extensions is not much harder than adding a 
symlink.  Easier, on versions of windows without symlinks :)

Sadly, Vista (I think) and 7 (for sure) restrict the  "assoc" and 
"ftype" commands with = signs, to being functional only in "Run as 
Administrator" shells, so on those versions, it is harder for the naïve 
to do the reconfigurations themselves.

The extra ftypes and assoc definitions can simply be copied from the 
existing ones, adding or changing a version number.  Would be much nicer 
if the installer did it for the naïve Windows user.


> The lack of near-universal symlink support on Windows filesystems is
> also an issue - we would have to duplicate files like python.exe and
> pythonw.exe on non-NTFS filesystems in order to provide them under
> alternative names.

Cheaper to make a couple copies of Python at install, than to bundle the 
whole Python environment in each application.

> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)

For Windows the status quo is pretty bad, so doing nothing is also 
pretty bad.  I agree the changes are "harder than an extra symlink" on 
Windows, but for someone that understand the installer, adding extra 
ftype and assoc is no harder, as it already knows how to install/replace 
that for .py files.

Sadly, there seems to be strong resistance to the idea of putting the 
Python install directory on the Windows path, of course, without some 
additional solutions (python2.exe, python3.exe, etc.), that doesn't help 
the multi-version install, only the single version install.

It would be _nice_, but harder, and harder to get consensus on, to write 
a little "python launcher" (in a compiled language, not Python, as that 
would double the startup time) to do some grunge on Windows.  Some 
possibilities, not all would be needed.

* Take over the Python.File ftype, look at the Unix #! line, extract the 
version, and run that version of Python from the installed Windows 
location for that version.

* Add .py2 & .py3 assoc and ftype for people that want to use 
Windows-like conventions to launch specific versions of Python.

* Could also add .py24, .py31, or even .py262, .py301, etc., assoc and 
ftype, depending on how many versions of Windows Python are installed.

* Support PYTHONxPATH, and convert to PYTHONPATH before launching 
pythonX.  Only needed if there are is a mix of python major versions 
installed, or PYTHONxPATH is defined in the environment.

* Implement a "Windows #! line" a line just after the "Unix #! line" 
that would specify what Windows executable should be run.  In this case, 
the first item should be adjusted, to use the Windows #! line when it 
exists, instead of extracting the version from the Unix #! line.  In the 
limit, this could be a general utility not limited to Python, that would 
provide Unix like execution of "Windows #! line"-aware applications, 
with or even without, file extensions (without is a little trickier, but 
apparently possible).  This would even allow the use of pythonw.exe to 
be specified for some scripts and not others... the script could choose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/c1f1313e/attachment.html>