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 '#! /usr/bin/python2') instead of plain 'python'. As part of the transition you're eventually going to want to let users change things so that /usr/bin/python is actually Python 3, and every Python 2 program that expects Python 2 to be /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 /usr/bin/python

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 using /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 own good.)