When Arch Linux switched its /usr/bin/python from python-2.x to python-3.x, it caused a little controversy… There were rumours that it had been decided upstream that /usr/bin/python would always point at a python-2.x install (although what version that should be was unclear). Although these rumours were abundant and so more than likely such a discussion did occur (probably offline at PyCon 2009), this decision was never documented. Also, whether such a decision can formally be made off the main development list is debatable.
Enter PEP 394. Depending on how I am feeling, I call this the “justify Arch’s treatment of python” PEP or the “make Debian include a python2 symlink” PEP. Either way, the basic outcome is:
- python2 will refer to some version of Python 2.x
- python3 will refer to some version of Python 3.x
- python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions
The PEP is still labeled as a draft, but all discussion is over as far as I can tell and I think it will probably be accepted without much of any further modification. The upshot is, using “#!/usr/bin/env python2” and “#!/usr/bin/env python3” in your code will become the gold standard (unless of course you code can run on both python-2.x and python-3.x). There is still no guarantee what versions of python-2.x or python-3.x you will get, but it is better than nothing…
One recommendation made by the PEP is that all distribution packages use the python2/python3 convention. That means the packages containing python-3.x code in Arch should have their shebangs changed to point at python3 rather than python. Given our experience doing the same thing with python2, this should not be too hard to achieve and is something that we should do once the PEP is out of draft stage. This has a couple of advantages. Firstly, we will likely get more success with upstream developers preparing their software to have a versioned python in their shebangs (or at least change all of them when installing with PYTHON=python2 ...). That would remove many sed lines from our PKGBUILDs. Secondly, if all packages only use python2 or python3, then the only use of the /usr/bin/python symlink would be interactively. That would mean that a system administrator could potentially change that symlink to point at any version of python that they wished.
Glad to see that all the hard works by the dev team finally pay off. 🙂
.. and it would allow us to easily implement python4 – whenever that comes out – without people busting our balls again 🙂
This all seems very pragmatic and sensible, and that has to be a good thing.
One question though – is there a chance that a standard or at least convention could arise that all Python 2 library packages are named “python2-.*”? A large number already are, but I do hit the occasional one that is not (python-lxml for example). It’s a bore having to install it and the pacman -Ql it to see which Python it’s for.
Possibly… maybe even probably… this is definitely an area that could use some clean-up. In the meantime, “pacman -Si” and looking the dependency list should save you having to install everything.
Given this PEP, the logical consequence would be that packages depending on Python 3 should also be named python3-* and there should be no python-* packages.
Well, not necessarily… I see the logical consequence is that python-* could be for python-2.x or python-3.x depending on what the distribution uses /usr/bin/python for.
Regarding Windows, see PEP 397: Python launcher for Windows. It proposes a launcher for Windows that evaluates shebang lines.
Also, NTFS symlinks created by “mklink” would be convenient. There could be a C:Python directory on the PATH that has symbolic links such as python.exe, python2.exe, python3.exe, python27.exe, python32.exe, etc, all of which would point to the PEP 397 console launcher, C:Pythonpy.exe. By adding .py to the PATHEXT environment variable, .py files on the PATH, or in the current directory, would also execute via the console launcher. Also, to clean up the C: root directory on Windows, it would be nice if the default installation was to C:PythonPython27, C:PythonPython32, etc.
Running “python27 script.py” might ask to run the script with python32 if its shebang indicates ‘python3’ — but a command line switch could override this. On the other hand, simply running “python script.py” would automatically choose the most appropriate version of Python, perhaps defaulting to the most recent version of python2 installed on the system, or a user configured default.
To avoid a console window for GUI scripts, just rename the .py extension to .pyw to use the C:Pythonpyw.exe launcher. Or instead of creating pyw.exe, a switch could be added to py.exe that simply hides the console window off screen the way apps such as console2 hide the win32 console in order to ‘replace’ it (there’s really no way to get rid of it completely).