On 3/4/2011 5:21 AM, Nick Coghlan wrote:

On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
<fuzzyman@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.