What Linux distributions should do to help their Python 3 transitions
After writing yesterday's entry, I've wound up with some opinions on what Linux distributions should be doing as part of any transition to Python 3. This isn't aimed at getting the programs they package ported to Python 3 (that's really up to the distributions and to the authors of the programs), but instead at encouraging general adoption of Python 3 among the people who use the distributions and who may write some Python code.
(I could generalize this to all operating system distributions, but I suspect that only some Linux distributions even care about this.)
First, if you haven't already created it there should be a
/usr/bin/python2. I suspect that everyone already has this; certainly
Fedora and Ubuntu do.
Now, make a packaging policy that all packaged Python 2 programs must
specifically use 'python2' (eg, start with '
instead of plain 'python'. As part of the transition you're eventually
going to want to let users change things so that
actually Python 3, and every Python 2 program that expects Python 2
/usr/bin/python is an obstacle to that. You can't do anything
about user programs, but you can and should make sure that your programs
aren't in the way.
(Once you do this, where
/usr/bin/python points should be put under
the control of your distribution's system for handling alternates.)
Next, you should arrange your standard OS installs (what people get if they pick the defaults for, say, a Gnome desktop or a web server) install Python 3 alongside Python 2 if Python 2 is installed by the standard install. Or to put it another way, any standard install should wind up with either no version of Python installed or both Python 2 and Python 3 installed; you should not have just Python 2 installed. The goal here is to encourage your users who use Python (or who may start using Python) to use Python 3 instead of Python 2 by at least making Python 3 available by default.
Packaged Python modules and extensions are a tricky situation. What you'd like is for there to be module parity between Python 2 and Python 3 where possible, assuming that you have Python 3 installed at all; when you install a Python module, it installs both the Python 2 and Python 3 versions at the same time. Unfortunately I don't think that any current package management system is this smart. The Debian package system at least has a 'recommended packages' option, so I think that all Python 2 modules could list any Python 3 equivalent as a recommended package.
(Again this has the goal of getting rid of obstacles to people writing Python 3 code; you want to avoid a situation where Python 2 is more attractive than Python 3 because it has a bunch of modules installed but your Python 3 install is very bare-bones.)
Sidebar: the thorny issue of
The following is not going to be a popular opinion, but it's what I
think is practical: if Python 2 is installed on the system at all,
/usr/bin/python should point to it by default (although you should
allow the sysadmin to change it if they want).
Why is simple: all of the user-written Python programs and scripts
and whatnot that are out there in the world. They're all currently
/usr/bin/python and expecting to get Python 2; if this becomes
Python 3 someday, the people with these programs are going to be what
sysadmins call 'very irritated'. If the system doesn't even have
Python 2 installed, you have a good excuse for it being Python 3;
/usr/bin/python can't run Python 2, because there's no Python 2 to
run. Otherwise there's no excuse.
(Yes, yes, making
/usr/bin/python be Python 3 would smack everyone
in the nose with the existence of Python 3 and might encourage some
people to port their code to Python 3. Let me assure you that by and
large people do not appreciate being smacked in the nose for their