<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>As an aside, this whole thing started when I tried installing <a href="http://www.ros.org/wiki/">ROS</a>, 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.</div>
<div><br></div><div>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.</div>
<div>.</div>PEP: ???<br> Title: The python Command on Unix-Like Systems<br> Version: ???<br> Last-Modified: ???<br> Author: Kerrick Staley <mail at <a href="http://kerrickstaley.com">kerrickstaley.com</a>><br> Status: Draft<br>
Type: Informational<div>Content-Type: text/x-rst<br> Created: 02-Mar-2011<br> Post-History: ???</div><div><br></div><div>Abstract</div><div>==========</div><div>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).</div>
<div><br></div><div>Recommendation</div><div>================</div><div><br></div><div>* ``*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.</div>
<div>* 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.</div>
<div><br></div><div>Rationale</div><div>===========</div><div><br></div><div>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.</div>
<div><br></div><div>Notes</div><div>=======</div><div><br></div><div>* Distributions can alias the "python" command to whichever version of the Python interpreter they choose.</div><div>* 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.</div>
<div>* 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.</div>
<div>* 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.</div>
<div>* 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.</div>
<div>* If these conventions are adhered to, it will be the case that the "python" command is only executed in an interactive manner.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<br>
</div><div>Backwards Compatibility</div><div>=========================</div><div>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.</div>
<div><br></div><div>Copyright</div><div><div>===========</div><div>This document has been placed in the public domain.</div><div><br></div><div>EOF</div><div><br></div><div>-Kerrick Staley</div><div><br><div class="gmail_quote">
On Wed, Mar 2, 2011 at 9:13 AM, James Y Knight <span dir="ltr"><<a href="mailto:foom@fuhm.net">foom@fuhm.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:<br>
> 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),<br>
<br>
</div>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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<font color="#888888"><br>
James<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com" target="_blank">http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com</a><br>
</div></div></blockquote></div><br></div></div>