<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 3/4/2011 5:21 AM, Nick Coghlan wrote:
<blockquote
cite="mid:AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
<a class="moz-txt-link-rfc2396E" href="mailto:fuzzyman@voidspace.org.uk"><fuzzyman@voidspace.org.uk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Should any of this also apply to Mac OS X and Windows?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Probably because Windows itself is so bloated -- so what is the
problem with a few extra copies of Python, one per application?<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<br>
Supporting .py2 and .py3 extensions is not much harder than adding a
symlink. Easier, on versions of windows without symlinks :)<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Cheaper to make a couple copies of Python at install, than to bundle
the whole Python environment in each application.<br>
<br>
<blockquote
cite="mid:AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com"
type="cite">
<pre wrap="">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 :)</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
* 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.<br>
<br>
* Add .py2 & .py3 assoc and ftype for people that want to use
Windows-like conventions to launch specific versions of Python.<br>
<br>
* Could also add .py24, .py31, or even .py262, .py301, etc., assoc
and ftype, depending on how many versions of Windows Python are
installed.<br>
<br>
* 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.<br>
<br>
* 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.<br>
</body>
</html>