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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
