subject:"\[Python\-Dev\] Support the \/usr\/bin\/python2 symlink upstream"

On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley m...@kerrickstaley.com wrote:
 PEP: ???
 Title: The python Utility on Unix-Like Systems

With a few adjustments (formatting, additional info, correction of
typos), I've now added Kerrick's PEP as a proposal on python.org:

http://www.python.org/dev/peps/pep-0394

The full text is included below as well.

Cheers,
Nick.

PEP: 394
Title: The python command on Unix-Like Systems
Version: $Revision: 88743 $
Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
Author: Kerrick Staley mail at kerrickstaley.com,
Nick Coghlan ncoghlan at gmail.com
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: 04-Mar-2011


Abstract


This PEP provides a convention to ensure that Python scripts can continue to
be portable across ``*nix`` systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the ``python`` command).

* ``python2`` will refer to some version of Python 2.x
* ``python3`` will refer to some version of Python 3.x
* ``python`` may refer to either, depending on distribution and system


Recommendation
==

* ``*nix`` software distributions should install the ``python2`` command into
  the default path whenever a version of the Python 2 interpreter is
  installed, and the same for ``python3`` and the Python 3 interpreter. When
  invoked, ``python2`` should run some version of the Python 2 interpreter,
  and ``python3`` should run some version of the Python 3 interpreter. The
  same applies for the more general ``python`` command, which should be
  installed whenever any version of Python is installed and should invoke
  some Python interpreter.
* All new code that needs to invoke the Python interpreter should not specify
  ``python``, but rather should specify either ``python2`` or ``python3`` (or
  the more specific ``python2.x`` and ``python3.x`` versions; see the Notes).
  This distinction should be made in shebangs, when invoking from a shell
  script, when invoking via the system() call, or when invoking in any other
  context. Note that, when reinvoking the interpreter from a Python script,
  querying ``sys.executable`` remains the preferred approach.


Rationale
=

This is needed as, even though the majority of distributions still alias the
``python`` command to Python 2, some now alias it to Python 3. Some of
the former also do not provide a ``python2`` command; hence, there is
currently no way for Python 2 code (or any code that invokes the Python 2
interpreter) to reliably run on all systems without modification, because both
the ``python`` and the ``python2`` commands will fail on some systems. The
recommendations in this PEP provide a very simple mechanism to restore
cross-platform support, with minimal additional work required on the part
of distribution maintainers.


Notes
=

* Distributions can alias the ``python`` command to whichever version of the
  Python interpreter they choose (noting that, in the near term, most 3rd
  party scripts will still expect this command to refer to Python 2.x).
* The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
  which they invoke specific minor versions of the Python interpreter. It
  would be wise for distribution-specific packages to take advantage of these
  utilities if they exist, since it will prevent code breakage if the default
  minor version of a given major version is changed. However, scripts
  intending to be cross-platform should not rely on the presence of these
  utilities, but rather should be tested on several recent minor versions of
  the target major version, compensating, if necessary, for the small
  differences that exist between minor versions. This prevents the need for
  sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
  ``python2``/``python3`` convention, even in code that is not intended to
  operate on other distributions. This will prevent problems if the
  distribution later decides to upgrade the version of the Python interpreter
  that the ``python`` command invokes, or if a sysadmin installs a custom
  ``python`` command with a different major version than the distribution
  default. Distributions can test whether they are fully following this
  convention by changing the ``python`` interpreter on a test box and checking
  to see if anything breaks.
* If the above point is adhered to and sysadmins are permitted to change the
  ``python`` command, then the ``python`` command should always be implemented
  as a link to the interpreter binary (or a link to a link) and not vice
  versa. That way, if a sysadmin does decide to replace the installed
  ``python`` file, they can do so without inadvertently deleting the
  previously installed binary.
* The first recommendation can be ignored for systems on which the ``python``
  command itself

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

2011-03-04 Thread Michael Foord


On 04/03/2011 12:10, Nick Coghlan wrote:

On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staleym...@kerrickstaley.com  wrote:

PEP: ???
Title: The python Utility on Unix-Like Systems

With a few adjustments (formatting, additional info, correction of
typos), I've now added Kerrick's PEP as a proposal on python.org:

http://www.python.org/dev/peps/pep-0394

The full text is included below as well.


Should any of this also apply to Mac OS X and Windows?

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.


All the best,

Michael Foord

[1] Activestate and Enthought in particular. Plus possibly others I'm 
not aware of.



Cheers,
Nick.

PEP: 394
Title: The python command on Unix-Like Systems
Version: $Revision: 88743 $
Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
Author: Kerrick Staleymail at kerrickstaley.com,
 Nick Coghlanncoghlan at gmail.com
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: 04-Mar-2011


Abstract


This PEP provides a convention to ensure that Python scripts can continue to
be portable across ``*nix`` systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the ``python`` command).

* ``python2`` will refer to some version of Python 2.x
* ``python3`` will refer to some version of Python 3.x
* ``python`` may refer to either, depending on distribution and system


Recommendation
==

* ``*nix`` software distributions should install the ``python2`` command into
   the default path whenever a version of the Python 2 interpreter is
   installed, and the same for ``python3`` and the Python 3 interpreter. When
   invoked, ``python2`` should run some version of the Python 2 interpreter,
   and ``python3`` should run some version of the Python 3 interpreter. The
   same applies for the more general ``python`` command, which should be
   installed whenever any version of Python is installed and should invoke
   some Python interpreter.
* All new code that needs to invoke the Python interpreter should not specify
   ``python``, but rather should specify either ``python2`` or ``python3`` (or
   the more specific ``python2.x`` and ``python3.x`` versions; see the Notes).
   This distinction should be made in shebangs, when invoking from a shell
   script, when invoking via the system() call, or when invoking in any other
   context. Note that, when reinvoking the interpreter from a Python script,
   querying ``sys.executable`` remains the preferred approach.


Rationale
=

This is needed as, even though the majority of distributions still alias the
``python`` command to Python 2, some now alias it to Python 3. Some of
the former also do not provide a ``python2`` command; hence, there is
currently no way for Python 2 code (or any code that invokes the Python 2
interpreter) to reliably run on all systems without modification, because both
the ``python`` and the ``python2`` commands will fail on some systems. The
recommendations in this PEP provide a very simple mechanism to restore
cross-platform support, with minimal additional work required on the part
of distribution maintainers.


Notes
=

* Distributions can alias the ``python`` command to whichever version of the
   Python interpreter they choose (noting that, in the near term, most 3rd
   party scripts will still expect this command to refer to Python 2.x).
* The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
   which they invoke specific minor versions of the Python interpreter. It
   would be wise for distribution-specific packages to take advantage of these
   utilities if they exist, since it will prevent code breakage if the default
   minor version of a given major version is changed. However, scripts
   intending to be cross-platform should not rely on the presence of these
   utilities, but rather should be tested on several recent minor versions of
   the target major version, compensating, if necessary, for the small
   differences that exist between minor versions. This prevents the need for
   sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
   ``python2``/``python3`` convention, even in code that is not intended to
   operate on other distributions. This will prevent problems if the
   distribution later decides to upgrade the version of the Python interpreter
   that the ``python`` command invokes, or if a sysadmin installs a custom
   ``python`` command with a different major version than the distribution
   default. Distributions can test whether they are fully following this
   convention by changing the ``python`` interpreter on a test box and checking
   to see if anything breaks.
* If the above point is adhered

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

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).

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.

 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 :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

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

2011-03-04 Thread Michael Foord


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

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

2011-03-04 Thread R. David Murray

On Fri, 04 Mar 2011 01:44:00 -0600, Kerrick Staley m...@kerrickstaley.com 
wrote:
 * All new code that needs to invoke the Python interpreter should not
 specify python, but rather should specify either python2 or python3
 (or the more specific python2.X and python3.X versions; see the Notes).
 This distinction should be made in shebangs, when invoking from a shell
 script, when invoking via the system() call, or when invoking in any other
 context.

If one target for this PEP is script implementors who hadn't thought
about this issue before, it is probably worth mentioning sys.executable
somewhere (a footnote?).

But another issue here (and this speaks against the proposal of not
shipping a /usr/bin/python link) is that it is quite possible to write
a script that will run on either python2 or python3. 

--
R. David Murray  www.bitdance.com
___
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

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

2011-03-04 Thread Westley Martínez

On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
 On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley m...@kerrickstaley.com 
 wrote:
  That way, if the sysadmin does decide to replace the installed python 
  file, he can do so without inadvertently deleting the previously installed 
  binary.
 
 Nit pick: Change he to they to be gender neutral.

Nit pick: Change they to he to be grammatically correct. If we
really have to be gender neutral, change he to he or she.

___
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

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

2011-03-04 Thread R. David Murray

On Fri, 04 Mar 2011 07:03:08 -0800, Westley =?ISO-8859-1?Q?Mart=EDnez?= 
aniko...@gmail.com wrote:
 On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
  On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley m...@kerrickstaley.com 
  wrote:
   That way, if the sysadmin does decide to replace the installed python 
   file, he can do so without inadvertently deleting the previously 
   installed binary.
  
  Nit pick: Change he to they to be gender neutral.
 
 Nit pick: Change they to he to be grammatically correct. If we
 really have to be gender neutral, change he to he or she.

English is evolving.  I vote for they.

--David
___
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

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

2011-03-04 Thread Isaac Morland


On Fri, 4 Mar 2011, R. David Murray wrote:


Nit pick: Change he to they to be gender neutral.


Nit pick: Change they to he to be grammatically correct. If we
really have to be gender neutral, change he to he or she.


English is evolving.  I vote for they.


Sorry, can't resist a further nitpick:  English has not been evolving in 
this particular case, in the sense that they has been used as a singular 
since before English was English:


http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/

Also interesting:

http://en.wikipedia.org/wiki/Singular_they

Attention he or sheists:  Singular they won before any of us was born. 
You may want to divert your energies to a more worthy cause, such as 
ensuring proper use of whom.


Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
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

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

On Fri, Mar 4, 2011 at 11:57 PM, R. David Murray rdmur...@bitdance.com wrote:
 On Fri, 04 Mar 2011 01:44:00 -0600, Kerrick Staley m...@kerrickstaley.com 
 wrote:
 * All new code that needs to invoke the Python interpreter should not
 specify python, but rather should specify either python2 or python3
 (or the more specific python2.X and python3.X versions; see the Notes).
 This distinction should be made in shebangs, when invoking from a shell
 script, when invoking via the system() call, or when invoking in any other
 context.

 If one target for this PEP is script implementors who hadn't thought
 about this issue before, it is probably worth mentioning sys.executable
 somewhere (a footnote?).

Including a mention of sys.executable is actually one of the changes I
made to Kerrick's text before uploading it as PEP 394.

 But another issue here (and this speaks against the proposal of not
 shipping a /usr/bin/python link) is that it is quite possible to write
 a script that will run on either python2 or python3.

Good point, the PEP should probably mention that.

Sleep is calling me right now, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

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

2011-03-04 Thread Steven D'Aprano


Westley Martínez wrote:

On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:

On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley m...@kerrickstaley.com wrote:

That way, if the sysadmin does decide to replace the installed python file, 
he can do so without inadvertently deleting the previously installed binary.

Nit pick: Change he to they to be gender neutral.


Nit pick: Change they to he to be grammatically correct. If we
really have to be gender neutral, change he to he or she.


Actually, that's a hyper-correction imposed by grammarians in the 18th 
century who were overly influenced by Latin. The use of they as a 
generic singular and indeterminate pronoun in written English goes back 
at least to Chaucer in the 14th century, and very likely as long back as 
before English was English, and remains in common use today. Despite the 
distaste for it among (mostly American) grammarians, it is 
linguistically sound and widely accepted in most of the English-speaking 
world, particularly England itself. The use of singular they is 
widespread, natural, and grammatically correct.


http://www.worldwidewords.org/qa/qa-the2.htm
http://en.wikipedia.org/wiki/Singular_they
http://itre.cis.upenn.edu/~myl/languagelog/archivs/005423.html

But for the sake of not upsetting our nuclear-armed cousins on the wrong 
side of the Atlantic *wink*, perhaps the sentence could be reworded to 
refer to system administrators plural, and thus satisfy everyone?


That way, if sysadmins decide to replace the installed python file, 
they can do so without inadvertently deleting the previously installed 
binary.




--
Steven
___
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

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

2011-03-04 Thread Ronald Oussoren

On 04 Mar, 2011,at 02:21 PM, Nick Coghlan ncogh...@gmail.com wrote:
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 :)Apple will generally follow what we decide to do for the base install.Anyway, I'd say that OSX should do the same as Unix platforms here and support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.RonaldP.S. I'm a bit confused about this discussion though, wouldn't adding python2 to the installation be a feature change and as such not something that can be done in a maintenance branch?
___
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

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

2011-03-04 Thread Kerrick Staley

 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.

The PEP makes a recommendation for all *nix platform, which includes Mac OS
X. I was not aware that Apple preinstalled Python on OS X, but it doesn't
really matter: Apple is the distribution maintainer, and they will be
expected to follow the recommendations of this PEP. Even if Apple is
sluggish in getting this change pushed out, it can be resolved on a
per-system basis by the sysadmin.

 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.)

I like your idea for Windows, but it would take time to implement this
solution, and we won't be able to finalize the solution for *nix as quickly
if we also provide a provision for Windows in this same PEP.

We should keep the use of the singular they; it's more popular than the
universal he (I intended the universal, rather than gender-specific,
meaning in the drafts of the PEP).

-Kerrick Staley

On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren ronaldousso...@mac.comwrote:



 On 04 Mar, 2011,at 02:21 PM, Nick Coghlan ncogh...@gmail.com wrote:


 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 :)


 Apple will generally follow what we decide to do for the base install.

 Anyway, I'd say that OSX should do the same as Unix platforms here and
 support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.

 Ronald

 P.S. I'm a bit confused about this discussion though, wouldn't adding
 python2 to the installation be a feature change and as such not something
 that can be done in a maintenance branch?

 ___
 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/mail%40kerrickstaley.com


___
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

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

2011-03-04 Thread Martin v. Löwis

 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.

Correct. IIUC (i.e. from the viewpoint of the PEP author), that's
deliberate. He just doesn't care about Windows, and, as a PEP author,
he clearly has the right to do so :-)

 
 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).

IMO, MacOS does fall under the rule of the PEP - it is unixish.
I agree with all things that Nick said, in particular with the
observation that Apple will do what Apple will do, no matter how
many PEPs we write. Our own make install, for OSX, should clearly
do something similar to what it does on other Unix systems.

 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.)

Here I also agree with Nick: the binary file name might be the least
issue. We had one bug report about 2.x and 3.x interference so far that
was difficult to track down - it seems that many Python users on Windows
set PYTHONPATH, and that is going to break Python 3 installations.

With that problem, and the extension problem, solving the exe name issue
doesn't actually resolve real problems.

Regards,
Martin
___
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

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

2011-03-04 Thread Martin v. Löwis

 P.S. I'm a bit confused about this discussion though, wouldn't adding
 python2 to the installation be a feature change and as such not
 something that can be done in a maintenance branch?

Correct. However, IMO, a PEP could propose to break that rule. Having
such a proposal may cause rejection of the PEP (or conditional
acceptance only if that change is not carried out). If the PEP is
accepted, a special case may be special enough to break the rules.

In addition, distributions can add all symlinks they like in their
packages, even if make install doesn't create them. Whether or not
*that* is a feature change depends on the distribution policy. For
example, for Debian, it would likely be perfectly reasonable to do
that in the 2.7 installation, since 2.7 will be a new feature for
Debian, anyway.

Regards,
Martin
___
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

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

2011-03-04 Thread Barry Warsaw

On Mar 03, 2011, at 08:09 PM, Toshio Kuratomi wrote:

Note to dmalcolm: IIRC, that also means that the Feature page you point to
isn't going to happen either.  Barry -- if other distros adopted stronger
policies, then that might justify me taking this back to the Packaging
Committee.

I know Scott Kitterman has talked about updating the Debian policy for various
issues.  Other Debian devs are on this list, but I'll bring it up over there
and get it on the radar.

-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-04 Thread Michael Foord


On 04/03/2011 17:45, Kerrick Staley wrote:
 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.

The PEP makes a recommendation for all *nix platform, which includes 
Mac OS X. I was not aware that Apple preinstalled Python on OS X, but 
it doesn't really matter: Apple is the distribution maintainer, and 
they will be expected to follow the recommendations of this PEP. Even 
if Apple is sluggish in getting this change pushed out, it can be 
resolved on a per-system basis by the sysadmin.




So there are three issues:

* What Apple does with the system install - out of our control but we 
can make recommendations

* What `make install` does on Mac OS X
* What the standard Mac OS X installer does

The last two of these are in our control. If we actually make changes to 
the build/install scripts of 2.7, rather than just recommendations for 
distributions, then it would be nice to see the changes in the installer 
as well as the build script. This would ultimately be up to Ronald or 
Ned who do the Mac OS X work of course.


 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.)

I like your idea for Windows, but it would take time to implement this 
solution, and we won't be able to finalize the solution for *nix as 
quickly if we also provide a provision for Windows in this same PEP.


I don't think duplicating python.exe as python2.exe or python3.exe would 
be very much work at all, if we decide it is a good thing. Sure it 
doesn't resolve all the myriad problems of Python on Windows but I don't 
think that is a good reason not to consider it. Up to Martin on this one 
though and again depends if we just make recommendations or actually 
change Python 2.7.


All the best,

Michael



We should keep the use of the singular they; it's more popular than 
the universal he (I intended the universal, rather than 
gender-specific, meaning in the drafts of the PEP).


-Kerrick Staley

On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren 
ronaldousso...@mac.com mailto:ronaldousso...@mac.com wrote:




On 04 Mar, 2011,at 02:21 PM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:


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 :)

Apple will generally follow what we decide to do for the base
install.

Anyway, I'd say that OSX should do the same as Unix platforms here
and support '#!/usr/bin/env python2'. Adding another symlink is
fairly trivial.

Ronald

P.S. I'm a bit confused about this discussion though, wouldn't
adding python2 to the installation be a feature change and as such
not something that can be done in a maintenance branch?

___
Python-Dev mailing list
Python-Dev@python.org mailto:Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com



___
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/fuzzyman%40voidspace.org.uk



--
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

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

2011-03-04 Thread R. David Murray

On Fri, 04 Mar 2011 15:50:01 +, Ronald Oussoren ronaldousso...@mac.com 
wrote:
 On 04 Mar, 2011,at 02:21 PM, Nick Coghlan ncogh...@gmail.com wrote:
 
 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 :)
 
 Apple will generally follow what we decide to do for the base install.
 
 Anyway, I'd say that OSX should do the same as Unix platforms here and support
 '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.

FYI, Ronald, the text version of your emails looses all quoting
information.  It would be nice if you could use standard email
quoting (leading '' characters).

 P.S. I'm a bit confused about this discussion though, wouldn't adding python2 
 to
 the installation be a feature change and as such not something that can be 
 done
 in a maintenance branch?

The purpose of the no new features rule is to prevent the situation
where a piece of code written for X.X.2 fails to run on X.X.1 because
it relies on a feature introduced in X.X.2.  In this situation, we
*already* have failures because scripts using /usr/bin/python2 that
run on one distro won't run on a different distro where that symlink
isn't defined.  In this case I don't think the no new features rule
can be applied blindly, because the feature has *already been introduced*
by third parties.  What we are attempting to do is make it *more* likely
that things will work in the future.

You can argue that having /usr/bin/python2 installed by 2.7.2 means
that code written for 2.7.2 that relies on it won't run on a vanilla
user-install of 2.7.1 or 2.7.  But how likely is that scenario compared
to the scenario where a script written for another distro fails to run
because /usr/bin/python2 doesn't exist?  I think the balance of the
argument comes down in favor of making the change, personally.

--
R. David Murray  www.bitdance.com
___
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

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

2011-03-04 Thread Barry Warsaw

On Mar 03, 2011, at 08:37 PM, Toshio Kuratomi wrote:

No, alternatives is really only useful for a very small class of problems
[1]_ and [2]_.

Thanks for the clarification.  I was on the fence about making the suggestion
in the first place. ;)

For this discussion there's an additional problem which is that alternatives
works by creating symlinks.  Piotr Ożarowski wants to make /usr/bin/python
not exist so that scripts would have to use either /usr/bin/python3 or
/usr/bin/python2.  If alternatives places a symlink there, it defeats the
purpose of avoiding that path in the package itself.

I don't agree that /usr/bin/python should not be installed.  The draft PEP
language hits the right tone IMHO, and I would favor /usr/bin/python pointing
to /usr/bin/python2 on Debian, but primarily used only for the interactive
interpreter.

Or IOW, I still want users to be able to type 'python' at a shell prompt and
get the interpreter.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-04 Thread Toshio Kuratomi

On Fri, Mar 04, 2011 at 01:56:39PM -0500, Barry Warsaw wrote:
 
 I don't agree that /usr/bin/python should not be installed.  The draft PEP
 language hits the right tone IMHO, and I would favor /usr/bin/python pointing
 to /usr/bin/python2 on Debian, but primarily used only for the interactive
 interpreter.
 
 Or IOW, I still want users to be able to type 'python' at a shell prompt and
 get the interpreter.
 
Actually, my post was saying that these two can be decoupled.  ie: It's
possible to not have /usr/bin/python while still allowing users to type
python at a shell prompt and get the interpreter.

This is done by either redefining the PATH to include the directory that the
interpreter named python is in or by creating an alias for python to the
proper interpreter.

Using the environment-modules tools is one solution that operated in this
way.  It also, incidentally, would let each user of a system choose whether
python invoked python2 or python3 (and on Debian, which sub-version of
those).  A more hardcoded approach is to have the python package drop some
configuration into /etc/profile.d/ style directories where the distribution
places files that are run by default by the user's shell with the default
startup files.

-Toshio


pgpVTu9R21jxR.pgp
Description: PGP signature
___
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

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

2011-03-04 Thread Glyph Lefkowitz

On Fri, Mar 4, 2011 at 10:03 AM, Westley Martínez aniko...@gmail.comwrote:

 On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
  On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley m...@kerrickstaley.com
 wrote:
   That way, if the sysadmin does decide to replace the installed python
 file, he can do so without inadvertently deleting the previously installed
 binary.
 
  Nit pick: Change he to they to be gender neutral.

 Nit pick: Change they to he to be grammatically correct. If we
 really have to be gender neutral, change he to he or she.


This grammatical rule is a modern fiction with no particular utility.  Go
ahead and use singular they as a gender-neutral pronoun; it was good
enough for Shakespeare, Twain, Austen and Shaw, it should be good enough for
Python.

http://en.wikipedia.org/wiki/Singular_they#Examples_of_generic_they
___
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

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

2011-03-04 Thread Martin v. Löwis

 I don't think duplicating python.exe as python2.exe or python3.exe would
 be very much work at all, if we decide it is a good thing. Sure it
 doesn't resolve all the myriad problems of Python on Windows but I don't
 think that is a good reason not to consider it. Up to Martin on this one
 though and again depends if we just make recommendations or actually
 change Python 2.7.

Changing the installer should be easy - there is a DuplicateFile table
in MSI (*) for this kind of installation task.

I'd still like the PEP to tell me whether it's python3w.exe or
pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
me). It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)

Regards,
Martin

(*) http://msdn.microsoft.com/en-us/library/aa368335(v=vs.85).aspx
___
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

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

2011-03-04 Thread Glenn Linderman


On 3/4/2011 5:21 AM, 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).

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.

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

2011-03-04 Thread Glenn Linderman


On 3/4/2011 1:35 PM, Martin v. Löwis wrote:

I'd still like the PEP to tell me whether it's python3w.exe or
pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
me). It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)


I agree the PEP should address these issues.  And since it is 
bikeshedding, as you say, I'm happy to just follow along.


I see no particular advantage to any of the choices, except that both 
w, and .exe are Windows-only things, so making it just like Unix + 
Windows-only things would seem more convenient, in some ways.  So I'll 
start the voting for


python VERSION [w] .exe

as the windows sequence.  Whatever form of VERSION, with or without 
dots, is done for Unix seems good for Windows too, as far as I can tell.
___
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

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

2011-03-04 Thread Brian Curtin

On Fri, Mar 4, 2011 at 16:04, Glenn Linderman v+pyt...@g.nevcal.com wrote:

 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.


FWIW, I plan on spending time on the PATH issue for 3.3. It seems like much
of the resistance could be quelled with actual code.

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.
 SNIP

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


-INF
___
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

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

2011-03-04 Thread Westley Martínez

On Sat, 2011-03-05 at 03:27 +1100, Steven D'Aprano wrote:
 Westley Martínez wrote:
  On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
  On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley m...@kerrickstaley.com 
  wrote:
  That way, if the sysadmin does decide to replace the installed python 
  file, he can do so without inadvertently deleting the previously 
  installed binary.
  Nit pick: Change he to they to be gender neutral.
  
  Nit pick: Change they to he to be grammatically correct. If we
  really have to be gender neutral, change he to he or she.
 
 Actually, that's a hyper-correction imposed by grammarians in the 18th 
 century who were overly influenced by Latin. The use of they as a 
 generic singular and indeterminate pronoun in written English goes back 
 at least to Chaucer in the 14th century, and very likely as long back as 
 before English was English, and remains in common use today. Despite the 
 distaste for it among (mostly American) grammarians, it is 
 linguistically sound and widely accepted in most of the English-speaking 
 world, particularly England itself. The use of singular they is 
 widespread, natural, and grammatically correct.
 
 http://www.worldwidewords.org/qa/qa-the2.htm
 http://en.wikipedia.org/wiki/Singular_they
 http://itre.cis.upenn.edu/~myl/languagelog/archivs/005423.html
 
 But for the sake of not upsetting our nuclear-armed cousins on the wrong 
 side of the Atlantic *wink*, perhaps the sentence could be reworded to 
 refer to system administrators plural, and thus satisfy everyone?
 
 That way, if sysadmins decide to replace the installed python file, 
 they can do so without inadvertently deleting the previously installed 
 binary.
 
 

All right I have to reply to all these singular they remarks. Just
because the singular they has been used for a long time doesn't make it
right. It sounds unnatural, at least to me, and I've always been taught
to use he or she which I despise. So all my life I've used the generic
he. Anyways, I remember reading somewhere that for Python Strunk and
White apply, and neither Strunk nor White like singular theys.

___
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

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

2011-03-04 Thread Guido van Rossum

On Fri, Mar 4, 2011 at 4:10 PM, Westley Martínez aniko...@gmail.com
 All right I have to reply to all these singular they remarks. Just
 because the singular they has been used for a long time doesn't make it
 right. It sounds unnatural, at least to me, and I've always been taught
 to use he or she which I despise. So all my life I've used the generic
 he. Anyways, I remember reading somewhere that for Python Strunk and
 White apply, and neither Strunk nor White like singular theys.

That's how I felt 20 years ago. But since then I've come to appreciate
they as a much better alternative to either he or she or he. Just
get used to it.

-- 
--Guido van Rossum (python.org/~guido)
___
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

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

2011-03-04 Thread Terry Reedy


On 3/4/2011 7:40 PM, Guido van Rossum wrote:

On Fri, Mar 4, 2011 at 4:10 PM, Westley Martínezaniko...@gmail.com

All right I have to reply to all these singular they remarks. Just
because the singular they has been used for a long time doesn't make it
right. It sounds unnatural, at least to me, and I've always been taught
to use he or she which I despise. So all my life I've used the generic
he. Anyways, I remember reading somewhere that for Python Strunk and
White apply, and neither Strunk nor White like singular theys.


That's how I felt 20 years ago.


I still feel that way ...


But since then I've come to appreciate
they as a much better alternative to either he or she or he. Just
get used to it.


But I discovered long ago that abstract singulars can nearly always be 
pluralized, as the statement is nearly always about people rather than 
any particular person.


--
Terry Jan Reedy


___
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

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

On Sat, Mar 5, 2011 at 8:04 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 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.

That's not the tricky part I was talking about - if .py2 and .py3 work
as scripts, the question arises as to whether or not they should work
as modules as well. The precedent set by .pyw is that they would, but
that then runs headling into Martin's question of how to spell
combinations of w with 2 and 3.

 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.

The key point for me is that the changes needed to significantly alter
the situation on Windows are far too invasive to be considered in a
maintenance release. A separate PEP proposing changes in this area for
Python 3.3 and later may be acceptable (especially if MvL is willing
to act as BDFOP*), but there really isn't a lot we can do for older
versions that is sufficiently low impact to justify breaking the no
new features rule.

Cheers,
Nick.

* Benevolent Dictator For One PEP, Guido's scheme where he delegates
the accept or reject decision for a given PEP to someone else.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

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

2011-03-03 Thread Martin v. Löwis

 Here is a draft PEP (forgive me if it's incorrectly formatted; I've
 never done this before).

LGTM. Please specify what /usr/bin/python is supposed to be also
(rather: the python utility). I'd like it ruled out that
installations *only* provide python2 and python3 - python could
be either one, but should be present normally (i.e. SHOULD
in the RFC 2119 sense).

Nitpickingly, I'd add that scripts can, of course, also specify
python2.7 (or some such). Actually, scripts can do whatever they
want - it's more about what they then can expect to happen.

Regards,
Martin
___
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

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

2011-03-03 Thread Piotr Ożarowski

[Guido van Rossum, 2011-03-02]
 On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski pi...@debian.org wrote:
  [Sandro Tosi, 2011-03-02]
  On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
   I co-maintain with Matthias a package that provides /usr/bin/python
   symlink in Debian and I can confirm that it will always point to Python
   2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
   only accepted PEP can change that)
 
  Can you please explain why you NACK this proposed change?
 
  it encourages people to change /usr/bin/python symlink to point to
  python3.X which I'm strongly against (how can I tell that upstream
  author meant python3.X and not python2.X without checking the code?)
 
 But the same is already true for python2.X vs. python2.Y. Explicit is
 better than implicit etc. Plus, 5 years from now everybody is going to
 be annoyed that python still refers to some ancient unused version
 of Python.

I don't really mind adding /usr/bin/python2 symlink just to clean Arch
mess, but I do mind changing /usr/bin/python to point to python3 (and I
can use the same argument - Explicit is better than implicit - if you
need Python 3, say so in the shebang, right?). What I'm afraid of is
when we'll add /usr/bin/python2, we'll start getting a lot of scripts
that will have to be checked manually every time new upstream version is
released because we cannot assume what upstream author is using at given
point.

If /usr/bin/python will be disallowed in shebangs on the other hand
(and all scripts will use /usr/bin/python2, /usr/bin/python3,
/usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
letting administrators choose /usr/bin/python (right now not only
changing it from python2.X to python3.X will break the system but also
changing it from /usr/bin/pytohn2.X to /usr/bin/python2.Y will break it,
and believe me, I know what I'm talking about (one of the guys at work
did something like this once))

[all IMHO, dunno if other Debian's python-defaults maintainers agree
with me]
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
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

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

2011-03-03 Thread Toshio Kuratomi

On Thu, Mar 03, 2011 at 09:55:25AM +0100, Piotr Ożarowski wrote:
 [Guido van Rossum, 2011-03-02]
  On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski pi...@debian.org wrote:
   [Sandro Tosi, 2011-03-02]
   On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
I co-maintain with Matthias a package that provides /usr/bin/python
symlink in Debian and I can confirm that it will always point to Python
2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
only accepted PEP can change that)
  
   Can you please explain why you NACK this proposed change?
  
   it encourages people to change /usr/bin/python symlink to point to
   python3.X which I'm strongly against (how can I tell that upstream
   author meant python3.X and not python2.X without checking the code?)
  
  But the same is already true for python2.X vs. python2.Y. Explicit is
  better than implicit etc. Plus, 5 years from now everybody is going to
  be annoyed that python still refers to some ancient unused version
  of Python.
 
 I don't really mind adding /usr/bin/python2 symlink just to clean Arch
 mess, but I do mind changing /usr/bin/python to point to python3 (and I
 can use the same argument - Explicit is better than implicit - if you
 need Python 3, say so in the shebang, right?). What I'm afraid of is
 when we'll add /usr/bin/python2, we'll start getting a lot of scripts
 that will have to be checked manually every time new upstream version is
 released because we cannot assume what upstream author is using at given
 point.
 
 If /usr/bin/python will be disallowed in shebangs on the other hand
 (and all scripts will use /usr/bin/python2, /usr/bin/python3,
 /usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
 letting administrators choose /usr/bin/python (right now not only
 changing it from python2.X to python3.X will break the system but also
 changing it from /usr/bin/pytohn2.X to /usr/bin/python2.Y will break it,
 and believe me, I know what I'm talking about (one of the guys at work
 did something like this once))
 
 [all IMHO, dunno if other Debian's python-defaults maintainers agree
 with me]

Thinking outside of the box, I can think of something that would satisfy
your requirements but I don't know how appropriate it is for upstream python
to ship with.  Stop shipping /usr/bin/python.  Ship python in an alternate
location like $LIBEXECDIR/python2.7/bin (I think this would be
/usr/lib/python2.7/bin on Debian and /usr/libexec/python2.7/bin on Fedora
which would both be appropriate) then configure which python version is
invoked by the user typing python by configuring PATH (a shell alias might
also work).  You could configure this with environment-modules[1]_ if Debian
supports using that in packaging.

Coupled with a PEP that recommends against using /usr/bin/python in scripts
and instead using /usr/bin/python$MAJOR, this might be sufficient.  OTOH, my
cynical side doubts that script authors read PEPs so it'll take either
upstream python shipping without /usr/bin/python or consensus among the
distros to ship without /usr/bin/python to reach the point where script
authors realize that they need to use /usr/bin/python{2,3} instead of
/usr/bin/python.

.. _[1]: http://modules.sourceforge.net/

-Toshio


pgp97oSsV2cOw.pgp
Description: PGP signature
___
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

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

2011-03-03 Thread David Malcolm

On Wed, 2011-03-02 at 01:14 +0100, Martin v. Löwis wrote:
  I think a PEP would help, but in this case I would request that before
  the PEP gets written (it can be a really short one!) somebody actually
  go out and get consensus from a number of important distros. Besides
  Barry, do we have any representatives of distros here?
 
 Matthias Klose represents Debian, Dave Malcolm represents Redhat,
 and Dirkjan Ochtman represents Gentoo.

Current status within RHEL and Fedora:
  The python rpm package has:
- a /usr/bin/python, which is the system build of Python 2
- hardlinked with /usr/bin/python2.N (where N is the appropriate
minor release number; currently 2.7 for Fedora 14 onwards)
- a symlink /usr/bin/python2, pointing at /usr/bin/python

  There are a number of other rpm packages with names matching *py*,
which use the system build of Python 3

  There is a python3 package on Fedora 13 onwards with:
- a /usr/bin/python3, which is the system build of Python 3
- hardlinked with /usr/bin/python3.N (where N is the appropriate
minor release number; will be 3.2 as of Fedora 15)

  There are number of add-on rpm packages containing 3rd-party Python 3
code with names of the form python3-*.

  Some more status on our pre-packaged Python 3 stack can be seen here:
 https://fedoraproject.org/wiki/Python3

  I've also added python-debug and python3-debug binaries,
containing --with-pydebug builds of the same code.

On a related note, we have a number of scripts packaged across the
distributions with a shebang line that reads:
   #!/usr/bin/env python
which AIUI follows upstream recommendations.

There was a proposal to change these when packaging them to hardcode the
specific python binary:

https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
on the grounds that a packaged system script is expecting (and has been
tested against) a specific python build.

That proposal has not yet been carried out.  Ideally if we did this,
we'd implement it as a postprocessing phase within rpmbuild, rather
than manually patching hundreds of files.

Note that this would only cover shebang lines at the tops of scripts.

If a 3rd-party program launches python directly, that could fail, and I
don't see a convenient way of fixing every reference in all code in all
packages (without, say, running a SystemTap script to monitor for
programs exec-ing /usr/bin/python)

For example, I wonder what the automake macro for detecting python would
make of a /usr/bin/python that's python 3:
  http://www.gnu.org/software/hello/manual/automake/Python.html
I've seen a few hand-coded makefiles for Python extension modules that
were broken by the SOABI changes in PEP 3149.  To be fair, thouse
makefiles were badly written, but I think that changing the meaning
of /usr/bin/python would break a lot of things.

FWIW, I don't see the harm in providing a /usr/bin/python2 symlink, but
I don't plan to change /usr/bin/python at this time.


Hope this is helpful
Dave


___
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

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

2011-03-03 Thread David Malcolm

On Thu, 2011-03-03 at 14:17 -0500, David Malcolm wrote:
 On Wed, 2011-03-02 at 01:14 +0100, Martin v. Löwis wrote:

   There are a number of other rpm packages with names matching *py*,
 which use the system build of Python 3
Gah; I meant Python 2 here.


(Must proofread my screeds before posting them)

___
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

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

2011-03-03 Thread James Y Knight

On Mar 3, 2011, at 3:55 AM, Piotr Ożarowski wrote:
 I don't really mind adding /usr/bin/python2 symlink just to clean Arch mess

Is there any chance you would add the symlink in the next Debian stable point 
release? If both Debian and Python upstream added the python2 symlink in the 
next stable update rather than waiting for the next major release (which for 
Python itself is of course never), that could reduce the problem of systems 
not having the symlink installed quite significantly.

James
___
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

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

2011-03-03 Thread Barry Warsaw

On Mar 03, 2011, at 09:55 AM, Piotr Ożarowski wrote:

I don't really mind adding /usr/bin/python2 symlink just to clean Arch
mess, but I do mind changing /usr/bin/python to point to python3 (and I
can use the same argument - Explicit is better than implicit - if you
need Python 3, say so in the shebang, right?). What I'm afraid of is
when we'll add /usr/bin/python2, we'll start getting a lot of scripts
that will have to be checked manually every time new upstream version is
released because we cannot assume what upstream author is using at given
point.

If /usr/bin/python will be disallowed in shebangs on the other hand
(and all scripts will use /usr/bin/python2, /usr/bin/python3,
/usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
letting administrators choose /usr/bin/python (right now not only
changing it from python2.X to python3.X will break the system but also
changing it from /usr/bin/pytohn2.X to /usr/bin/python2.Y will break it,
and believe me, I know what I'm talking about (one of the guys at work
did something like this once))

[all IMHO, dunno if other Debian's python-defaults maintainers agree
with me]

This all seems reasonable to me, except that I think it would be good at some
point -- which might be in several years -- to point /usr/bin/python to
python3.  We are not there now, but I do think we will be there one day.

I also don't think we have to worry about a Python 4.  I'm skeptical it will
ever happen, because really, how many big warts in Python 3 do you think we'll
need to break in a backward incompatible way?  If it does, and history holds
true, it'll be 15 years from now.  Then all you whippersnappers can do
whatever you like. :)

-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-03 Thread Barry Warsaw

On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:

On a related note, we have a number of scripts packaged across the
distributions with a shebang line that reads:
   #!/usr/bin/env python
which AIUI follows upstream recommendations.

Actually, I think this is *not* a good idea for distro provided scripts.  For
any Python scripts released by the distro, you know exactly which Python it
should run on, so it's better to hard code it.  That way, if someone installs
Python from source, or installs an experimental version of a new distro
Python, it won't break their system.  Yes, this has happened to me.  Also,
note that distutils/setuptools/distribute rewrite the shebang line when they
install scripts.

There was a proposal to change these when packaging them to hardcode the
specific python binary:

https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
on the grounds that a packaged system script is expecting (and has been
tested against) a specific python build.

That proposal has not yet been carried out.  Ideally if we did this,
we'd implement it as a postprocessing phase within rpmbuild, rather
than manually patching hundreds of files.

Note that this would only cover shebang lines at the tops of scripts.

JFDI!

FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
Ubuntu.  We should fix these. ;)

-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-03 Thread Barry Warsaw

On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:

Thinking outside of the box, I can think of something that would satisfy
your requirements but I don't know how appropriate it is for upstream python
to ship with.  Stop shipping /usr/bin/python.  Ship python in an alternate
location like $LIBEXECDIR/python2.7/bin (I think this would be
/usr/lib/python2.7/bin on Debian and /usr/libexec/python2.7/bin on Fedora
which would both be appropriate) then configure which python version is
invoked by the user typing python by configuring PATH (a shell alias might
also work).  You could configure this with environment-modules[1]_ if Debian
supports using that in packaging.

I wonder if Debian's alternatives system would be appropriate for this?

http://wiki.debian.org/DebianAlternatives

-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-03 Thread Toshio Kuratomi

On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:

On a related note, we have a number of scripts packaged across the
distributions with a shebang line that reads:
#!/usr/bin/env python
which AIUI follows upstream recommendations.

Actually, I think this is *not* a good idea for distro provided scripts. For
any Python scripts released by the distro, you know exactly which Python it
should run on, so it's better to hard code it. That way, if someone installs
Python from source, or installs an experimental version of a new distro
Python, it won't break their system. Yes, this has happened to me. Also,
note that distutils/setuptools/distribute rewrite the shebang line when they
install scripts.

There was a proposal to change these when packaging them to hardcode the
specific python binary:

https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
on the grounds that a packaged system script is expecting (and has been
tested against) a specific python build.

That proposal has not yet been carried out. Ideally if we did this,
we'd implement it as a postprocessing phase within rpmbuild, rather
than manually patching hundreds of files.

Note that this would only cover shebang lines at the tops of scripts.

JFDI!

FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
Ubuntu. We should fix these. ;)

Note, we were unable to pass Guideline changes to do this in Fedora. Gory
details of the FPC meeting are at 16:15:03 (abadger1999 == me):
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html

The mailing list thread where this was discussed is here:
http://lists.fedoraproject.org/pipermail/packaging/2009-July/006248.html

Note to dmalcolm: IIRC, that also means that the Feature page you point to
isn't going to happen either. Barry -- if other distros adopted stronger
policies, then that might justify me taking this back to the Packaging
Committee.

-Toshio

pgpeLOL8uwMOh.pgp
Description: PGP signature
___
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

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

2011-03-03 Thread Toshio Kuratomi

On Thu, Mar 03, 2011 at 09:46:23PM -0500, Barry Warsaw wrote:
 On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:
 
 Thinking outside of the box, I can think of something that would satisfy
 your requirements but I don't know how appropriate it is for upstream python
 to ship with.  Stop shipping /usr/bin/python.  Ship python in an alternate
 location like $LIBEXECDIR/python2.7/bin (I think this would be
 /usr/lib/python2.7/bin on Debian and /usr/libexec/python2.7/bin on Fedora
 which would both be appropriate) then configure which python version is
 invoked by the user typing python by configuring PATH (a shell alias might
 also work).  You could configure this with environment-modules[1]_ if Debian
 supports using that in packaging.
 
 I wonder if Debian's alternatives system would be appropriate for this?
 
 http://wiki.debian.org/DebianAlternatives
 


No, alternatives is really only useful for a very small class of problems
[1]_ and [2]_.  For this discussion there's an additional problem which is
that alternatives works by creating symlinks.  Piotr Ożarowski wants to make
/usr/bin/python not exist so that scripts would have to use either
/usr/bin/python3 or /usr/bin/python2.  If alternatives places a symlink
there, it defeats the purpose of avoiding that path in the package itself.

I will note, though that scripts that have /usr/bin/env and take the route
of setting the PATH would still fall victim to this.  I think that
environment-modules can also set up aliases.  If so, that wouldbe better
than setting PATH for finding and removing python without a version in
scripts.

One further note on this since one of the other messages here had
a reference to this that kinda rains on this parade:
http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Languages/LSB-Languages/pylocation.html

The LSB is a standard that Linux distributions may or may not follow --
unlike the FHS, the LSB goes beyond encoding what most distros already do to
things that they think people should do.  For instance, Debian derivatives
might find the software installation section of LSB[3]_ to be a bit... hard
to swallow.  Fedora provides a package which aims to make a fedora system
lsb compliant but doesn't install it by default since it drags in gobs of
packages that are otherwise not necessary on many systems.

However, it does specify /usr/bin/python so getting rid of /usr/bin/python
at the Linux distribution level might not reach universal aclaim.  A united
front from upstream python through the python package maintainers on the
Linux distros would probably be needed to get people thinking about making
this change... and we still would likely have the ability to add
/usr/bin/python back onto a system (for instance, as part of that lsb
package I mentioned earlier.)

.. [1]:
https://fedoraproject.org/wiki/Packaging:EnvironmentModules#Introduction
.. [2]:
http://fedoraproject.org/wiki/Packaging:Alternatives#Recommended_usage

.. [3]:
http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html

-Toshio


pgpRUO8y9NO0L.pgp
Description: PGP signature
___
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

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

2011-03-03 Thread Kerrick Staley

LGTM. Please specify what /usr/bin/python is supposed to be also
(rather: the python utility). I'd like it ruled out that
installations *only* provide python2 and python3 - python could
be either one, but should be present normally (i.e. SHOULD
in the RFC 2119 sense).

Nitpickingly, I'd add that scripts can, of course, also specify
python2.7 (or some such). Actually, scripts can do whatever they
want - it's more about what they then can expect to happen.
Good points--I've taken them into account in the revised PEP, which I will
send to this list shortly.
OTOH, my
cynical side doubts that script authors read PEPs so it'll take either
upstream python shipping without /usr/bin/python or consensus among the
distros to ship without /usr/bin/python to reach the point where script
authors realize that they need to use /usr/bin/python{2,3} instead of
/usr/bin/python.
I don't see this as an issue: all it will take is for one user with a
different python to contact a developer once, referring the developer to
the PEP, and then every program that that developer ever writes in the
future will be fixed (and, if the developer's worth anything, every program
he's already written, as well). Word of mouth tends to pass these things
around quickly.
Actually, I think this is *not* a good idea for distro provided scripts.
For
any Python scripts released by the distro, you know exactly which Python
it
should run on, so it's better to hard code it. That way, if someone
installs
Python from source, or installs an experimental version of a new distro
Python, it won't break their system.
I agree. I would personally like it if distributions would provide a python
utility that can be changed by the sysadmin without breaking anything, but
implementing such a thing would be too much to ask from many distros, so I
left it out of the first draft of the PEP. I'll put into the Notes in the
second draft, though.

Again, I think that the nature of the python utility is a decision that
belongs squarely to the distributions (it'll likely evolve into an everyone
else is doing it sort of issue for distros like Debian that don't like to
change without good reason). On the other hand, ensuring that cross-platform
support exists is an issue that should be handled by a central authority.

I almost added provisions to the second draft of the PEP for things like
python2.6, since the same issue basically exists with them, so it would be
logical to also address their support. However, since there are far fewer
cases where minor version changes break code, and far more cases where a
specific minor version of the Python interpreter isn't and doesn't need to
be installed, I imagine a problem will occur if we make pythonX.X
standard: developers will use the pythonX.X invocations instead of
ensuring their code works on all (recent) versions of the interpreter, and
much larger issues will arise when users are forced to repeatedly install
different minor versions of the interpreter. I instead addressed this topic
in the Notes section.

-Kerrick Staley

On Thu, Mar 3, 2011 at 10:09 PM, Toshio Kuratomi a.bad...@gmail.com wrote:

On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:

On a related note, we have a number of scripts packaged across the
distributions with a shebang line that reads:
#!/usr/bin/env python
which AIUI follows upstream recommendations.

Actually, I think this is *not* a good idea for distro provided scripts.
For
any Python scripts released by the distro, you know exactly which Python
it
should run on, so it's better to hard code it. That way, if someone
installs
Python from source, or installs an experimental version of a new distro
Python, it won't break their system. Yes, this has happened to me.
Also,
note that distutils/setuptools/distribute rewrite the shebang line when
they
install scripts.

There was a proposal to change these when packaging them to hardcode the
specific python binary:

https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
on the grounds that a packaged system script is expecting (and has been
tested against) a specific python build.

That proposal has not yet been carried out. Ideally if we did this,
we'd implement it as a postprocessing phase within rpmbuild, rather
than manually patching hundreds of files.

Note that this would only cover shebang lines at the tops of scripts.

JFDI!

FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
Ubuntu. We should fix these. ;)

Note, we were unable to pass Guideline changes to do this in Fedora. Gory
details of the FPC meeting are at 16:15:03 (abadger1999 == me):

http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html

The mailing list thread where this was discussed is here:

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

2011-03-03 Thread Kerrick Staley

PEP: ???
Title: The python Utility on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley mail at kerrickstaley.com
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???

Abstract
==
This PEP provides a convention to ensure that Python scripts can continue to
be portable across *nix systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the python utility).

Recommendation


* ``*nix`` software distributions should install the python2 utility into
the default path whenever a version of the Python 2 interpreter is
installed, and the same for python3 and the Python 3 interpreter. When
invoked, python2 should run some version of the Python 2 interpreter, and
python3 should run some version of the Python 3 interpreter. The same
applies for the more general python command, which should should be
installed whenever any version of Python is installed and should invoke some
Python interpreter.
* All new code that needs to invoke the Python interpreter should not
specify python, but rather should specify either python2 or python3
(or the more specific python2.X and python3.X versions; see the Notes).
This distinction should be made in shebangs, when invoking from a shell
script, when invoking via the system() call, or when invoking in any other
context.

Rationale
===

This is needed because some distributions alias the python command to
Python 3, while others alias it to Python 2. Some of the latter also do not
provide a python2 command; hence, there is no way for Python 2 code (or
any code that invokes the Python 2 interpreter) to reliably run on all
systems without modification, because both the python and the python2
commands will fail on some systems. The recommendations in this PEP provide
a very simple mechanism to restore cross-platform support, with very little
additional work required on the part of distribution maintainers.

Notes
===

* Distributions can alias the python command to whichever version of the
Python interpreter they choose.
* The pythonX.X (e.g. python2.6) utilities exist on some systems, on
which they invoke specific minor versions of the Python interpreter. It
would be wise for distribution-specific packages to take advantage of these
utilities if they exist, since it will prevent code breakage if the default
minor version of a given major version is changed. However, scripts
intending to be cross-platform should not rely on the presence of these
utilities, but rather should be tested on several recent minor versions of
the target major version, compensating, if necessary, for the small
differences that exist between minor versions. This prevents the need for
sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
python2/python3 convention, even in code that is not intended to operate
on other distributions. This will prevent problems if the distribution
decides to upgrade the version of the Python interpreter that the python
command invokes, or if the sysadmin installs a custom python utility with
a different major version than the distribution default. Distributions can
test whether they are fully following this convention by changing the
python interpreter on a test box and checking to see if anything breaks.
* If the above point is adhered to and sysadmins are permitted to change the
python utility, then the python utility should always be implemented as
link to the interpreter binary (or a link to a link) and not vice versa.
That way, if the sysadmin does decide to replace the installed python
file, he can do so without inadvertently deleting the previously installed
binary.
* The first recommendation can be ignored for systems on which the python
command itself has traditionally been left undefined and users have always
had the responsibility of linking the python command to the Python
interpreter.
* If the Python 2 interpreter becomes uncommon, scripts should nevertheless
continue to use the python3 convention rather that just python. This
will ease transition in the event that yet another major version of Python
is released.
* If these conventions are adhered to, it will be the case that the python
utility is only executed in an interactive manner.

Backwards Compatibility
=
A potential problem can arise if a script adhering to the
python2/python3 convention is executed on a system not supporting these
commands. This is mostly a non-issue, since the sysadmin can simply create
these symbolic links and avoid further problems.

Copyright
===
This document has been placed in the public domain.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:

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

[Martin v. Löwis, 2011-03-02]
  I think a PEP would help, but in this case I would request that before
  the PEP gets written (it can be a really short one!) somebody actually
  go out and get consensus from a number of important distros. Besides
  Barry, do we have any representatives of distros here?
 
 Matthias Klose represents Debian, Dave Malcolm represents Redhat,
 and Dirkjan Ochtman represents Gentoo.

I co-maintain with Matthias a package that provides /usr/bin/python
symlink in Debian and I can confirm that it will always point to Python
2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
only accepted PEP can change that)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
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

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

2011-03-02 Thread Jeroen Ruigrok van der Werven

-On [20110302 01:17], Martin v. Löwis (mar...@v.loewis.de) wrote:
Matthias Klose represents Debian, Dave Malcolm represents Redhat,
and Dirkjan Ochtman represents Gentoo.

With FreeBSD's ports if you install a Python port it will install a
pythonX.Y in /usr/local/bin, depending on what is specified with the make
variable PYTHON_DEFAULT_VERSION python will point to that version. So it
can refer to either 2.x or 3.x.

NetBSD's pkgsrc does not have 3.x in the tree yet. But if no python exists
yet, then pkg_alternatives will link it to the version of choice.

Not sure what either OpenBSD or DragonFly BSD are doing, but it will be
along these lines as well.

-- 
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | GPG: 2EAC625B
Ain't gonna spend the rest of my Life, quietly fading away...
___
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

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

2011-03-02 Thread Michael Foord


On 01/03/2011 21:19, Kerrick Staley wrote:

Hello,
There is a need for the default Python2 install to place a symlink at 
/usr/bin/python2 that points to /usr/bin/python, or for the 
documentation to recommend that packagers ensure that python2 is 
defined. Also, all documentation should be changed to recommend that 
#!/usr/bin/env python2 be used as the shebang for Python 2 scripts.
This is needed because some distributions (Arch Linux, in particular), 
point /usr/bin/python to /usr/bin/python3, while others (including 
Slackware, Debian, and the BSDs, probably more) do not even define the 
python2 command. This means that a script has no way of achieving 
cross-platform compatibility. The point at which many distributions 
begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and 
for the next couple of years, it would be best to use a python2 or 
python3 shebang in all scripts, making no assumptions about plain 
python, which should only be invoked interactively. This email from 
about 3 years ago seems relevant: : 
http://mail.python.org/pipermail/python-3000/2008-March/012421.html
Again, this issue needs to be addressed by the Python developers 
themselves so that different *nix distributions will handle it 
consistently, allowing Python scripts to continue to be cross-platform.


+1

Note that a PEP will need to address what we do for Windows and Mac OS 
X. Less of an issue for Windows where we don't put python.exe on the 
PATH (which we *should*), but we still need to decide whether we will 
add python2 / python3 binaries.


Michael Foord


Thanks,
Kerrick Staley


___
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/fuzzyman%40voidspace.org.uk



--
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

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

2011-03-02 Thread Sandro Tosi

On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
 I co-maintain with Matthias a package that provides /usr/bin/python
 symlink in Debian and I can confirm that it will always point to Python
 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
 only accepted PEP can change that)

Can you please explain why you NACK this proposed change?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
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

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

[Sandro Tosi, 2011-03-02]
 On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
  I co-maintain with Matthias a package that provides /usr/bin/python
  symlink in Debian and I can confirm that it will always point to Python
  2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
  only accepted PEP can change that)
 
 Can you please explain why you NACK this proposed change?

it encourages people to change /usr/bin/python symlink to point to
python3.X which I'm strongly against (how can I tell that upstream
author meant python3.X and not python2.X without checking the code?)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
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

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

2011-03-02 Thread Sandro Tosi

On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski pi...@debian.org wrote:
 [Sandro Tosi, 2011-03-02]
 On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
  I co-maintain with Matthias a package that provides /usr/bin/python
  symlink in Debian and I can confirm that it will always point to Python
  2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
  only accepted PEP can change that)

 Can you please explain why you NACK this proposed change?

 it encourages people to change /usr/bin/python symlink to point to
 python3.X which I'm strongly against (how can I tell that upstream
 author meant python3.X and not python2.X without checking the code?)

with 'people' do you mean 'users'? if so, isn't this risk already present?

If you, user, change the python symlink (provided by python-minimal in
Debian) to something else than what's shipped, it's still a local
change, and will never be supported; but with python2 *Debian is free*
to decide if python can be pointed to python3, if the time will come.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
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

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

[Sandro Tosi, 2011-03-02]
 On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski pi...@debian.org wrote:
  [Sandro Tosi, 2011-03-02]
  On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
   I co-maintain with Matthias a package that provides /usr/bin/python
   symlink in Debian and I can confirm that it will always point to Python
   2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
   only accepted PEP can change that)
 
  Can you please explain why you NACK this proposed change?
 
  it encourages people to change /usr/bin/python symlink to point to
  python3.X which I'm strongly against (how can I tell that upstream
  author meant python3.X and not python2.X without checking the code?)
 
 with 'people' do you mean 'users'? if so, isn't this risk already present?

users already break their systems via sudo ez_install ... (note the
sudo part!), I meant developers (distro and upstream authors).
If a programmer develops a script in Python 3 on Arch and later ships
his file with /usr/bin/python in shebang, it's very likely that this
script will not work on all distributions that didn't (yet?) change the
symlink.

 If you, user, change the python symlink (provided by python-minimal in
 Debian) to something else than what's shipped, it's still a local
 change, and will never be supported; but with python2 *Debian is free*
 to decide if python can be pointed to python3, if the time will come.

... and make other distributions developers' life miserable?
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
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

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


On Mar 2, 2011, at 8:23 AM, Sandro Tosi wrote:

 On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski pi...@debian.org wrote:
 [Sandro Tosi, 2011-03-02]
 On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
 I co-maintain with Matthias a package that provides /usr/bin/python
 symlink in Debian and I can confirm that it will always point to Python
 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
 only accepted PEP can change that)
 
 Can you please explain why you NACK this proposed change?
 
 it encourages people to change /usr/bin/python symlink to point to
 python3.X which I'm strongly against (how can I tell that upstream
 author meant python3.X and not python2.X without checking the code?)
 
 with 'people' do you mean 'users'? if so, isn't this risk already present?
 
 If you, user, change the python symlink (provided by python-minimal in
 Debian) to something else than what's shipped, it's still a local
 change, and will never be supported; but with python2 *Debian is free*
 to decide if python can be pointed to python3, if the time will come.

I suspect he's saying it'd be better if the time didn't come (if so, I'd 
agree). Python3 *is* unfortunately a new and incompatible programming language, 
it makes sense for it to have it have its own interpreter name. Eventually 
/usr/bin/python might no longer be installed, but that doesn't mean python3 
shouldn't simply be called python3 forever.

James
___
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

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

2011-03-02 Thread Jérôme Radix

Hello,

Defensive programming will force you to do things like :

import sys
if sys.version[0] == '2':
___
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

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

2011-03-02 Thread Allan McRae


On 03/03/11 00:03, Piotr Ożarowski wrote:

[Sandro Tosi, 2011-03-02]

On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowskipi...@debian.org  wrote:

[Sandro Tosi, 2011-03-02]

On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowskipi...@debian.org  wrote:

I co-maintain with Matthias a package that provides /usr/bin/python
symlink in Debian and I can confirm that it will always point to Python
2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
only accepted PEP can change that)


Can you please explain why you NACK this proposed change?


it encourages people to change /usr/bin/python symlink to point to
python3.X which I'm strongly against (how can I tell that upstream
author meant python3.X and not python2.X without checking the code?)


with 'people' do you mean 'users'? if so, isn't this risk already present?


users already break their systems via sudo ez_install ... (note the
sudo part!), I meant developers (distro and upstream authors).
If a programmer develops a script in Python 3 on Arch and later ships
his file with /usr/bin/python in shebang, it's very likely that this
script will not work on all distributions that didn't (yet?) change the
symlink.


If you, user, change the python symlink (provided by python-minimal in
Debian) to something else than what's shipped, it's still a local
change, and will never be supported; but with python2 *Debian is free*
to decide if python can be pointed to python3, if the time will come.


... and make other distributions developers' life miserable?


But is that not the whole point of adding the /usr/bin/python2 symlink. 
 That way a developer can explicitly use a /usr/bin/python2 or 
/usr/bin/python3 shebang and have it portable everywhere.  At the 
moment, Debian seems to be the major hold-up on that actually being a 
reality being the only major distro I could find that does not provide 
such a symlink.


Note also that even restricting /usr/bin/python to point at a python-2.x 
binary gives no guarantee on what actual python-2.x version you are 
getting, so it is not as if guaranteeing portability is not a problem 
already...


Allan
___
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

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

2011-03-02 Thread Michael Foord


On 02/03/2011 14:04, James Y Knight wrote:

On Mar 2, 2011, at 8:23 AM, Sandro Tosi wrote:


On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowskipi...@debian.org  wrote:

[Sandro Tosi, 2011-03-02]

On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowskipi...@debian.org  wrote:

I co-maintain with Matthias a package that provides /usr/bin/python
symlink in Debian and I can confirm that it will always point to Python
2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
only accepted PEP can change that)

Can you please explain why you NACK this proposed change?

it encourages people to change /usr/bin/python symlink to point to
python3.X which I'm strongly against (how can I tell that upstream
author meant python3.X and not python2.X without checking the code?)

with 'people' do you mean 'users'? if so, isn't this risk already present?

If you, user, change the python symlink (provided by python-minimal in
Debian) to something else than what's shipped, it's still a local
change, and will never be supported; but with python2 *Debian is free*
to decide if python can be pointed to python3, if the time will come.

I suspect he's saying it'd be better if the time didn't come (if so, I'd 
agree). Python3 *is* unfortunately a new and incompatible programming language,


Only partly true. It's a new version of an existing language that 
introduces backwards incompatible changes. It *isn't* a new language and 
I write code that happily runs under Python 2 (2.4+) and 3.


Michael


  it makes sense for it to have it have its own interpreter name. Eventually 
/usr/bin/python might no longer be installed, but that doesn't mean python3 
shouldn't simply be called python3 forever.

James
___
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/fuzzyman%40voidspace.org.uk



--
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

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

[Allan McRae, 2011-03-02]
 But is that not the whole point of adding the /usr/bin/python2 symlink.  
 That way a developer can explicitly use a /usr/bin/python2 or  
 /usr/bin/python3 shebang and have it portable everywhere.  At the moment, 
 Debian seems to be the major hold-up on that actually being a reality 
 being the only major distro I could find that does not provide such a 
 symlink.

Do you realize how many (still perfectly usable) scripts written in
Python 2.x few years ago (and not modified since then) are out there?
Do you realize how much work would it require to fix every single one
of them to point to /usr/bin/python2 instead? Even if we'd start checking
mdate and change it at build time automatically, there still will be way
too many false positives... for no clear gain.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
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

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

2011-03-02 Thread Allan McRae


On 03/03/11 00:29, Piotr Ożarowski wrote:

[Allan McRae, 2011-03-02]

But is that not the whole point of adding the /usr/bin/python2 symlink.
That way a developer can explicitly use a /usr/bin/python2 or
/usr/bin/python3 shebang and have it portable everywhere.  At the moment,
Debian seems to be the major hold-up on that actually being a reality
being the only major distro I could find that does not provide such a
symlink.


Do you realize how many (still perfectly usable) scripts written in
Python 2.x few years ago (and not modified since then) are out there?
Do you realize how much work would it require to fix every single one
of them to point to /usr/bin/python2 instead? Even if we'd start checking
mdate and change it at build time automatically, there still will be way
too many false positives... for no clear gain.


Having made the packages using python-2.x code from an entire 
distribution point at /usr/bin/python2, I have a fair idea of how much 
work is involved...


And that is exactly why changes need made now so that time is available 
for transition.  Providing the /usr/bin/python2 symlink now means that 
any future code would be able to point to it rather than some 
unversioned python binary.  That way in ?? years when python-3.x is 
the python and python-2.x is obsolete, and it is decided that 
/usr/bin/python will be python-3.x (which I believe is the only logical 
outcome), then everyone will be a lot more prepared.


Allan
___
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

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

On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:
 That way in ?? years when python-3.x is the python and python-2.x is 
 obsolete, and it is decided that /usr/bin/python will be python-3.x (which I 
 believe is the only logical outcome), 

But that's not the only logical outcome. A perfectly logical outcome is that 
/usr/bin/python disappears completely if python2.X isn't installed, and python3 
is always called python3. That is the outcome I find sensible. And that is the 
crux of the disagreement in this thread. 


Those who think python3.X should stay /usr/bin/python3 forever do not see any 
reason to make everyone rewrite their existing python scripts to say 
/usr/bin/python2 instead of /usr/bin/python. So, there's no point in adding 
a /usr/bin/python2 now. Scripts that want python2 can remain using 
/usr/bin/python forever, and that will either be installed, or not installed, 
depending on whether that OS has a copy of python2.X.

Those who think python3 should (eventually someday, or maybe immediately, 
depending) be named or have an alias of /usr/bin/python want to make everyone 
rewrite their scripts to say /usr/bin/python2 now. For that position, it's 
unfortunate that python source doesn't install itself with an alias of 
/usr/bin/python2, and some distros don't install that alias either. So they 
want to fix that.

James
___
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

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

[Allan McRae, 2011-03-02]
 Having made the packages using python-2.x code from an entire  
 distribution point at /usr/bin/python2, I have a fair idea of how much  
 work is involved...

* is every Arch package that uses Python 2.X already working with
  /usr/bin/python and why not? ;-)
* how many Python packages do Arch have in the first place and why so
  little? ;-)
* how does Arch deal with scripts that are not packaged, what do you say
  to users who report bugs against your packages because their local
  scripts do not work anymore? :-|
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
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

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

2011-03-02 Thread Nick Coghlan

/tangent

Does this discussion remind anyone else of the bash/dash switch for
/usr/bin/sh in Ubuntu?

The distro itself coped fine, but 3rd party shell scripts that used
bash extensions were a whole different story.

(No, I'm not sure what lessons, if any, we can draw from that. It just
struck me as an interesting parallel worth mentioning)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

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

2011-03-02 Thread R. David Murray

On Wed, 02 Mar 2011 10:13:59 -0500, James Y Knight f...@fuhm.net wrote:
 On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:
  That way in ?? years when python-3.x is the python and python-2.x
  is obsolete, and it is decided that /usr/bin/python will be
  python-3.x (which I believe is the only logical outcome), 
 
 But that's not the only logical outcome. A perfectly logical outcome
 is that /usr/bin/python disappears completely if python2.X isn't
 installed, and python3 is always called python3. That is the outcome I
 find sensible. And that is the crux of the disagreement in this
 thread.

Well, I personally won't use a distribution that makes this choice.
For whatever that's worth :)

But, even if a distribution *does* make that choice, if it wants to
be compatible with code developed on distributions that make
the other choice, it should provide a /usr/bin/python2 symlink.
Otherwise, it is going to be getting bug reports from users asking
why XYZ script doesn't run.

In short, I don't see any *downside* to providing a /usr/bin/python2
symlink.

--
R. David Murray  www.bitdance.com
___
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

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

2011-03-02 Thread Barry Warsaw

On Mar 02, 2011, at 03:29 PM, Piotr Ożarowski wrote:

[Allan McRae, 2011-03-02]
 But is that not the whole point of adding the /usr/bin/python2 symlink.  
 That way a developer can explicitly use a /usr/bin/python2 or  
 /usr/bin/python3 shebang and have it portable everywhere.  At the moment, 
 Debian seems to be the major hold-up on that actually being a reality 
 being the only major distro I could find that does not provide such a 
 symlink.

Do you realize how many (still perfectly usable) scripts written in
Python 2.x few years ago (and not modified since then) are out there?
Do you realize how much work would it require to fix every single one
of them to point to /usr/bin/python2 instead? Even if we'd start checking
mdate and change it at build time automatically, there still will be way
too many false positives... for no clear gain.

There's no need to require that change.  In Debian, /usr/bin/python can
continue point to python2 for a very long time.

I don't have a problem with adding such a symlink, and I think it should be
done by Informational PEP, not Standards Track PEP.  Since there will be no
Python 2.8, our own build system shouldn't ever be changed to add such a link,
but we can recommend it for consistency among distros, which would be free to
adopt it or not.

-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-02 Thread Guido van Rossum

On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski pi...@debian.org wrote:
 [Sandro Tosi, 2011-03-02]
 On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
  I co-maintain with Matthias a package that provides /usr/bin/python
  symlink in Debian and I can confirm that it will always point to Python
  2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
  only accepted PEP can change that)

 Can you please explain why you NACK this proposed change?

 it encourages people to change /usr/bin/python symlink to point to
 python3.X which I'm strongly against (how can I tell that upstream
 author meant python3.X and not python2.X without checking the code?)

But the same is already true for python2.X vs. python2.Y. Explicit is
better than implicit etc. Plus, 5 years from now everybody is going to
be annoyed that python still refers to some ancient unused version
of Python.

If it takes a PEP to change your position, let's write the PEP.

-- 
--Guido van Rossum (python.org/~guido)
___
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

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

2011-03-02 Thread Steven D'Aprano


Jérôme Radix wrote:

Hello,

Defensive programming will force you to do things like :

import sys
if sys.version[0] == '2':



Really? Do you already do this?

if sys.version  '2.2':
result = apply(func, arguments)
else:
result = func(*arguments)


And if so, have you tested it in Python 1.5 to see what happens?



--
Steven
___
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

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

On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
 I don't have a problem with adding such a symlink, and I think it should be
 done by Informational PEP, not Standards Track PEP.  Since there will be no
 Python 2.8, our own build system shouldn't ever be changed to add such a link,
 but we can recommend it for consistency among distros, which would be free to
 adopt it or not.

Why not? 2.7 is supposed to be in long term maintenance mode. Surely if it's a 
good idea for everyone else to ship a python2 binary, 2.7.next should also 
install it when building from source...

James
___
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

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

On Mar 2, 2011, at 11:42 AM, R. David Murray wrote:
 Well, I personally won't use a distribution that makes this choice.
 For whatever that's worth :)

This ***shouldn't*** be a choice distros have to make. There should be a 
standard upstream recommended way to install python, and that's also what make 
install should do. That distros are having to make a choice here is a problem 
in communication from python core developers -- it sucks that we've gotten this 
far without consensus on a proper transition plan for moving from Python 2.X to 
Python 3.X.

James
___
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

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

2011-03-02 Thread Steven D'Aprano


James Y Knight wrote:


I suspect he's saying it'd be better if the time didn't come (if so,
I'd agree). Python3 *is* unfortunately a new and incompatible
programming language, it makes sense for it to have it have its own
interpreter name. 



Oh come on, there's like three incompatibilities versus three thousand 
things that are compatible. A pox on your discontinuous mind! *wink*


Seriously, most of the changes are library changes, not language 
changes. The similarities far outweigh the differences. I don't think 
there is a generally agreed upon objective boundary between dialect 
and language, but to my mind the change between 2.x and 3.x falls 
squarely under dialect.


In the same way, I don't care that William Shakespeare's everyday speech 
would be nearly incomprehensible to my ears, and mine to his, we both 
speak (spoke?) English.


In my opinion, the biggest change from Python 2 - 3 is that we actually 
provide developers tools for migrating scripts rather than leave it for 
them to deal with the changes themselves. I recently ported a client's 
application written for 2.3 that used string exceptions everywhere to 
2.6. I would have loved a 2.3to2.6 fixer :) I don't consider 2.3 and 
2.6 to be different languages, and I suspect neither do you, even though 
code that runs fine without even a warning under one raises a 
SyntaxError under the other.


Every time we drop or rename a module from the standard library, we 
break scripts. Such backwards incompatibility is not enough to delineate 
different languages. Even syntax changes are not necessarily enough.




Eventually /usr/bin/python might no longer be
installed, but that doesn't mean python3 shouldn't simply be called
python3 forever.


I already call Python 3 python in casual conversation. There is *no 
way* that I will be calling it python3 in fifteen years time, when 
Python 2.7 is as dead and forgotten as Python 1.5 is now, just to 
satisfy some overly strict definition of different language.




--
Steven
___
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

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

2011-03-02 Thread Barry Warsaw

On Mar 02, 2011, at 02:49 PM, James Y Knight wrote:

On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
 I don't have a problem with adding such a symlink, and I think it should be
 done by Informational PEP, not Standards Track PEP.  Since there will be no
 Python 2.8, our own build system shouldn't ever be changed to add such a 
 link,
 but we can recommend it for consistency among distros, which would be free to
 adopt it or not.

Why not? 2.7 is supposed to be in long term maintenance mode. Surely if it's
a good idea for everyone else to ship a python2 binary, 2.7.next should also
install it when building from source...

Seems like it's straying into new feature territory to me, but then I'm not
the 2.7 RM.  OTOH, if it really does help Python 3 adoption, it might be worth 
it.

-Barry


signature.asc
Description: PGP signature
___
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

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

2011-03-02 Thread Steven D'Aprano


Steven D'Aprano wrote:

Jérôme Radix wrote:

Hello,

Defensive programming will force you to do things like :

import sys
if sys.version[0] == '2':



Really? Do you already do this?

if sys.version  '2.2':
result = apply(func, arguments)
else:
result = func(*arguments)


And if so, have you tested it in Python 1.5 to see what happens?


Sorry, that reads harsher than I intended. Please insert a wink and a 
smiley.




--
Steven
___
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

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

2011-03-02 Thread Martin v. Löwis

Am 02.03.2011 20:49, schrieb James Y Knight:
 On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
 I don't have a problem with adding such a symlink, and I think it
 should be done by Informational PEP, not Standards Track PEP.
 Since there will be no Python 2.8, our own build system shouldn't
 ever be changed to add such a link, but we can recommend it for
 consistency among distros, which would be free to adopt it or not.
 
 Why not? 2.7 is supposed to be in long term maintenance mode. Surely
 if it's a good idea for everyone else to ship a python2 binary,
 2.7.next should also install it when building from source...

I agree with Barry that this would be a new feature, and, by default,
cannot be added to the 2.7 release which is in maintenance mode.

IMO, an accepted PEP could override the policy, though.

Regards,
Martin
___
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

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


On Mar 2, 2011, at 5:04 PM, Martin v. Löwis wrote:

 Am 02.03.2011 20:49, schrieb James Y Knight:
 On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
 I don't have a problem with adding such a symlink, and I think it
 should be done by Informational PEP, not Standards Track PEP.
 Since there will be no Python 2.8, our own build system shouldn't
 ever be changed to add such a link, but we can recommend it for
 consistency among distros, which would be free to adopt it or not.
 
 Why not? 2.7 is supposed to be in long term maintenance mode. Surely
 if it's a good idea for everyone else to ship a python2 binary,
 2.7.next should also install it when building from source...
 
 I agree with Barry that this would be a new feature, and, by default,
 cannot be added to the 2.7 release which is in maintenance mode.
 
 IMO, an accepted PEP could override the policy, though.

That sounds like an entirely reasonable position to take.

All the more reason for someone who's in favor of python3 being called python 
in the future to write the PEP outlining how to ease the transition by 
providing a python2 link now.

James
___
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

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

2011-03-02 Thread Jérôme Radix

No, I don't do it now. But taking like granted the fact that 2.x python will
be dead in 5 years and that /usr/bin/python will point to python3 is, imho,
a little too optimistic. Thus, as time passes, python scripts will have to
guess if they are running through python3 or python2 because the two will be
installed on most systems, with no strict convention on how to run a 2.x
python script or a 3.x python script.

/usr/bin/python is meant to point to python3 one time or another. The time
will never be the same for all distros.

And, yes, people are already testing python version in their
scriptshttp://www.google.com/search?q=python+version+test+site%3Astackoverflow.comie=utf-8
.

As a matter of fact, they've already had this kind of discussion for Perl :
they use require http://perldoc.perl.org/functions/require.html.


Jérôme.


2011/3/2 Steven D'Aprano st...@pearwood.info

 Steven D'Aprano wrote:

 Jérôme Radix wrote:

 Hello,

 Defensive programming will force you to do things like :

 import sys
 if sys.version[0] == '2':



 Really? Do you already do this?

 if sys.version  '2.2':
result = apply(func, arguments)
 else:
result = func(*arguments)


 And if so, have you tested it in Python 1.5 to see what happens?


 Sorry, that reads harsher than I intended. Please insert a wink and a
 smiley.




 --
 Steven
 ___
 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/jerome.radix%40gmail.com

___
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

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

2011-03-02 Thread Martin v. Löwis

Am 02.03.2011 23:36, schrieb Jérôme Radix:
 No, I don't do it now. But taking like granted the fact that 2.x python
 will be dead in 5 years and that /usr/bin/python will point to python3
 is, imho, a little too optimistic.

I don't think Steven said, or assumed, a scope of 5 years - more like
a scope of 30 years. In 30 years, Python 2 will surely be dead (as
will likely be Python 3).

The defensive programming you promote is likely to fail. Many Python 2
scripts are syntactically invalid when interpreted as Python 3, so a
version test won't even be executed.

With separate python2 and python3 executables, people can have scripts
depend on the right binary.

In interactive mode, I would like to use /usr/bin/python be the
current Python binary always (even when Python 4.6 comes along).
Python will, interactively, greet me with its version number, and I
can adjust. So the idea of /usr/bin/python being reserved for Python 2
strikes me as inconvenient.

Regards,
Martin
___
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

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

2011-03-02 Thread Westley Martínez

On Wed, 2011-03-02 at 16:20 +0100, Piotr Ożarowski wrote:
 [Allan McRae, 2011-03-02]
  Having made the packages using python-2.x code from an entire  
  distribution point at /usr/bin/python2, I have a fair idea of how much  
  work is involved...
 
 * is every Arch package that uses Python 2.X already working with
   /usr/bin/python and why not? ;-)
 * how many Python packages do Arch have in the first place and why so
   little? ;-)
 * how does Arch deal with scripts that are not packaged, what do you say
   to users who report bugs against your packages because their local
   scripts do not work anymore? :-|

Is that a silver spoon in your mouth?

___
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

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

2011-03-02 Thread Guido van Rossum

On Wed, Mar 2, 2011 at 3:00 PM, Martin v. Löwis mar...@v.loewis.de wrote:
 Am 02.03.2011 23:36, schrieb Jérôme Radix:
 No, I don't do it now. But taking like granted the fact that 2.x python
 will be dead in 5 years and that /usr/bin/python will point to python3
 is, imho, a little too optimistic.

 I don't think Steven said, or assumed, a scope of 5 years - more like
 a scope of 30 years. In 30 years, Python 2 will surely be dead (as
 will likely be Python 3).

 The defensive programming you promote is likely to fail. Many Python 2
 scripts are syntactically invalid when interpreted as Python 3, so a
 version test won't even be executed.

 With separate python2 and python3 executables, people can have scripts
 depend on the right binary.

 In interactive mode, I would like to use /usr/bin/python be the
 current Python binary always (even when Python 4.6 comes along).
 Python will, interactively, greet me with its version number, and I
 can adjust. So the idea of /usr/bin/python being reserved for Python 2
 strikes me as inconvenient.

+1 on all that.

-- 
--Guido van Rossum (python.org/~guido)
___
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

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

2011-03-02 Thread Kerrick Staley

The point is that there never has to be an agreement about the python
command, as long as all distros support python2/python3 and all scripts use
it (I think that the distinction should continue to be made if/when python2
becomes uncommon, otherwise we'll hit the same issue with python4). We don't
have to force anyone to change the python command itself.

That being said, I feel that the python command should only be invoked from
an interactive terminal, and in fact it would be good if distros would use
the python2/python3 convention in their own packages, so that the sysadmin
can point python to wherever he wants, and when he types python into a
terminal get the version he wants. As an added plus, should a distro
supporting this feature decide to make the Python 2 - Python 3 switch, it
would be an effortless process. Again, however, force this requirement
shouldn't be forced on distros.

As an aside, this whole thing started when I tried installing
ROShttp://www.ros.org/wiki/,
only to find that it made assumptions about /usr/bin/python, which points to
python3 on my Arch Linux system. I went in search of documentation for the
python2/python3 convention so that I could make the ROS developers aware of
it and help them to follow it, only to find out that no such convention
actually exists. Since ROS uses a rather complicated python-based installer
that makes assumptions about /usr/bin/python not only in the shebangs of
many files but also in other places (apparently in connection with the
subprocess module), it has proven thus far unworkable unless I change
/usr/bin/python back to Python 2, a move that could potentially break many
other aspects of my system. I'm sure there are many other users out there
that are frustrated by similar issues; supporting a python2/python3
convention on all distros as well as in scripts would solve these issues
without creating further problems and without the need for a slow consensus
to be reached on what /usr/bin/python should be.

Here is a draft PEP (forgive me if it's incorrectly formatted; I've never
done this before). I think it's a little long winded given how simple the
idea it proposes is, but I thought it would be better to be more specific
than necessary rather than less.
.
PEP: ???
Title: The python Command on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley mail at kerrickstaley.com
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???

Abstract
==
This PEP provides a convention to ensure that Python scripts can continue to
be portable across *nix systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the python command).

Recommendation


* ``*nix`` software distributions should install the command python2 into
the default path whenever a version of the Python 2 interpreter is
installed, and the same for python3 and the Python 3 interpreter. When
invoked, python2 should run some version of the Python 2 interpreter, and
python3 should run some version of the Python 3 interpreter.
* All new code that needs to invoke the Python interpreter should specify
either python2 or python3, according to the version it requires, but not
python. This distinction should be made in shebangs, when invoking from a
shell script, when invoking via the system() call, or when invoking in any
other context.

Rationale
===

This is needed because some distributions alias the python command to
Python 3, while others alias it to Python 2. Some distributions also do not
provide a python2 command; hence, there is no way for Python 2 code (or
any code that invokes the Python 2 interpreter) to reliably run on all
systems without modification, because both the python and the python2
commands will fail on some systems. The recommendations in this PEP provide
a very simple mechanism to restore cross-platform support, with very little
additional work required on the part of distribution maintainers.

Notes
===

* Distributions can alias the python command to whichever version of the
Python interpreter they choose.
* It would be wise for distributions to always follow the convention that
this PEP recommends, even in code that is not intended to operate on other
distributions. This will make it easier if the code ever needs to be ported
to another distribution or if the distribution decides to change the version
of the Python interpreter that the python command invokes. Distributions
can test whether they are fully following this convention by switching the
python interpreter and seeing if anything breaks.
* If the above point is adhered to, then the python command should always
be a link to the interpreter binary (or a link to a link) and not vice
versa. That way, if users decide to change where the python command
points, they can do so without inadvertently deleting the binary.
* The first recommendation can be ignored for systems on which the python

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