On 04/03/2011 13:21, Nick Coghlan wrote:
On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
<fuzzy...@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).
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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
