On 04/03/2011 13:21, Nick Coghlan 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
On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote: think Kerrick did a good job of summarising the position that has been expressed in this thread).
Right, but the pep doesn't address those issues for some fairly major platforms.
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.
However on Mac OS X at least *scripts* have the same issue (what to put in the shebang line).
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).
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.
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 :)
Right, but on Mac OS X we do put a "python3" on the path but not a "python2". We also create "python2.x" and "python3.x" variants. So the same issues exist yet the pep On Windows we only have a "python.exe" I believe, but if the user does put their Python installs on the path then we *could* usefully create "python2.exe" and "python3.exe" for them. I don't see that duplicating these binaries on the filesystem is an issue. File associations is just unsolvable on Windows, so it isn't something we can address or should worry about. (Actually a stub python.exe that looks at the shebang line and then delegates to the appropriate pythonX.Y.exe would be a possibility but I'm not volunteering to write it.) All the best, Michael
Cheers, Nick.
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html