Python 3 on the desktop for Quantal Quetzal

Written by Barry Warsaw in technology on Tue 24 April 2012. Tags: canonical, debian, ubuntu, python, python3,

So, now all the world now knows that my suggested code name for Ubuntu 12.10, Qwazy Quahog, was not chosen by Mark. Oh well, maybe I'll have more luck with Racy Roadrunner.

In any case, Ubuntu 12.04 LTS is to be released any day now so it's time for my semi-annual report on Python plans for Ubuntu. I seem to write about this every cycle, so 12.10 is no exception. We've made some fantastic progress, but now it's time to get serious.

For Ubuntu 12.10, we've made it a release goal to have Python 3 only on the desktop CD images. The usual caveats apply: Python 2.7 isn't going away; it will still probably always be available in the main archive. This release goal also doesn't affect other installation CD images, such as server, or other Ubuntu flavors. The relatively modest goal then only affects packages for the standard desktop CD images, i.e. the alternative installation CD and the live CD.

Update 2012-04-25: To be crystal clear, if you depend on Python 2.7, the only thing that changes for you is that after a fresh install from the desktop CD on a new machine, you'll have to explicitly apt-get install *python2.7 . After that, everything else will be the same.

This is ostensibly an effort to port a significant chunk of Ubuntu to Python 3, but it really is a much wider, Python-community driven effort. Ubuntu has its priorities, but I personally want to see a world where Python 3 rules the day, and we can finally start scoffing at Python 2 :).

Still, that leaves us with about 145 binary packages (and many fewer source packages) to port. There are a few categories of packages to consider:

Already ported and available. This is the good news, and covers packages such as dbus-python. Unfortunately, there aren't too many others, but we need to check with Debian and make sure we're in sync with any packages there that already support Python 3 (python3-dateutil comes to mind). Upstream supports Python 3, but it is not yet available in Debian or Ubuntu. These packages should be fairly easy to port, since we have pretty good packaging guidelines for supporting both Python 2 and Python 3. Packages with better replacements for Python 3. A good example is the python-simplejson package. Here, we might not care as much because Python 3 already comes with a json module in its standard library, so code which depends on python-simplejson and is required for the desktop CD, should be ported to use the stdlib json module. python-gobject is another case where porting is a better option, since pygi (gobject-introspection) already supports Python 3. Canonical is the upstream. Many packages in the archive, such as python-launchpadlib and python-lazr.restfulclient are developed upstream by Canonical. This doesn't mean you can't or shouldn't help out with the porting of those modules, it's just that we know who to lean on as a last resort. By all means, feel free to contribute to these too! Orphaned by upstream. These are the most problematic, since there's essentially no upstream maintainer to contribute patches to. An example is python-oauth. In these cases, we need to look for alternatives that are maintained upstream, and open to porting to Python 3. In the case of python-oauth, we need to f investigate oauth2, and see if there are features we're using from the abandoned package that may not be available in the supported one. Unknowns. Well, this one's the big risky part because we don't know what we don't know.

We need your help! First of all, there's no way I can personally port everything on our list, including both libraries and applications. We may have to make some hard choices to drop some functionality from Ubuntu if we can't get it ported, and we don't want to have to do that. So here are some ways you can contribute:

Fill in the spreadsheet with more information. If you're aware of an upstream or Debian port to Python 3, let us know. It may make it easier for someone else to enable the Python 3 version in Debian, or to shepherd the upstream patch to landing on their trunk.

Help upstream make a Python 3 port available. There are lots of resources available to help you port some code, from quick references to in-depth guides. There's also a mailing list (and Gmane newsgroup mirror) you can join to get help, report status, and have other related discussions. Some people have asked Python 3 porting questions on StackOverflow, using the tags #python , #python-3.x , and #porting .

, , and . Join us on the #python3 IRC channel on Freenode.

IRC channel on Freenode. Subscribe to the python-porting mailing list.

Get packages ported in Debian. Once upstream supports Python 3, you can extend the existing Debian package to expose this support into Debian. From there, you or we can make sure that gets sync'd into Ubuntu.

Spread the word! Even if you don't have time to do any ports yourself, you can help publicize this effort through social media, mailing lists, and your local Python community. This really is a Python-wide effort!

Python 3.3 is scheduled to be released later this year. Please help make 2012 the year that Python 3 reached critical mass!

On a more personal note, I am also committed to making Mailman 3 a Python 3 application, but right now I'm blocked on a number of dependencies. Here are the list of dependencies from the setup.py file, and their statuses. I would love it if you help get these ported too!

argparse - unnecessary as Python 3 has this in its standard library

flufl.bounce - all the flufl packages support Python 3 already!

packages support Python 3 already! flufl.enum

flufl.i18n

flufl.lock

flufl.password

httplib2 - PyPI page claims to support Python 3

lazr.config - needs porting

lazr.smtptest - needs porting

mock - supports Python 3!

restish - needs porting

storm - needs porting

zc.buildout - needs porting (or we could finally ditch it)

zope.component - zope.interface has basic ZCA support so the

has basic ZCA support so the dependency may be removable. zope.component itself isn't ported yet.

itself isn't ported yet. zope.configuration - needs porting

zope.interface - supports Python 3!

zope.testing - supports Python 3!

Of course, these are only the direct dependencies. Others that get pulled in include: