Revision 42 as of 2011-07-17 16:27:53

Clear message

Should I use Python 2 or Python 3 for my development activity?

What are the differences?

Short version: Python 2.x is the status quo, Python 3.x is the shiny new thing.

At the time of writing (July 4, 2010), the final 2.7 release is out, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active and continued development, with 3.2 already available.

3.x is the newest branch of Python and the intended future of the language. Guido van Rossum (the original creator of the Python language) decided to clean up Python 2.x properly, with less regard for backwards compatibility than is the case for new releases in the 2.x range. This allowed several aspects of the core language (such as print and exec being statements, integers using floor division) to be adjusted to be easier for newcomers to learn and to be more consistent with the rest of the language. It also allowed later language features (such as iterators) to be applied to older language features (such as the range builtin which returns a list in 2.x, but a memory efficient iterable in 3.x).

The What's New in Python 3.0 document provides a good overview of the major language changes and likely sources of incompatibility with existing Python 2.x code.

However, the broader Python ecosystem has amassed a significant amount of quality software over the years. The downside of breaking backwards compatibility in 3.x is that a lot of that software doesn't work on 3.x yet.

So which version should I use?

Which version you ought to use is mostly dependent on what you want to get done.

If you can do exactly what you want with Python 3.x, great! There's a few downsides, such as comparatively limited library support and the fact that most current Linux distributions and Macs are still using 2.x as default, but as a language Python 3.x is definitely ready. As long as actually getting Python 3.x on your user's computers (which ought to be easy since a lot of people reading this may only be developing something for themselves or an environment they control) and you're writing things where lack of third party software isn't a major impediment (or where you know the packages you need already support Python 3), Python 3.x is an excellent choice. Also, several distributions have Python 3.x already installed or available for end-users.

However, there are some key issues that may require you to use Python 2 rather than Python 3.

Firstly, if you're deploying to an environment you don't control, that may impose a specific version rather than allowing you a free selection from the available versions.

Secondly, if you want to use a specific third party package or utility that doesn't yet have a released version that is compatible with Python 3, and porting that package is a non-trivial task, you may choose to use Python 2 in order to retain access to that package.

Popular modules that don't yet support Python 3 include Twisted (for networking and a bunch of other stuff), gevent (like Twisted but different), Django and Pylons (for building websites), PyGTK1 and PySide (for making GUIs), py2exe (for packaging your application for Windows users), PIL (for processing images)...

Most of these libraries have people working on 3.x support and it's mostly a work in progress in various stages of completion. For some libraries, it's more of a priority than others: Twisted, for example, is mostly focused on production servers, where supporting older versions of Python is important, let alone supporting a new version that includes major changes to the language. (Twisted is a prime example of a major package where porting to 3.x is far from trivial.)

Of course, many packages have already been ported to 3.x. For example, people who want GUI functionality could use PyQt, PyGobject or Tkinter (shipped with the standard library). And for number crunching, numpy supports Python 3 since version 1.5. If you want to use Python 3.x, but you're afraid to because of a dependency, it's probably worthwhile doing some research first: again, this is a work in progress and this wiki page might be outdated.

Even if the official python documentation and the tutorial have been updated for Python 3, there is still a lot of documentation (including examples) on the web and in reference books that still use Python 2. This can require some adjustment to make things work with Python 3 instead.

Python 3 Porting Status

But wouldn't I want to avoid 2.x? It's an old language with a bunch of mistakes, and it took a major version to get 'em out.

Well, not really. The good news is that you don't have to drop all of the 3.x goodness because you're using 2.x. A lot of the good ideas in 3.0 were backported to 2.6, and even more of the good ideas from 3.0, 3.1 and 3.2 are available in 2.7. The number of things that you really can't do in 2.x but can in 3.x is pretty small: it's just not always as elegant as it is in 3.x. A non-exhaustive list of features which are only available in 3.x releases and most likely won't be backported to the 2.x series:

For more details on the backported features, see What's New in Python 2.6 and What's New in Python 2.7.

Well written 2.x code will actually be a lot like 3.x code. That can mean a lot of things, including using new-style classes, not using ancient deprecated arcane incantations of print, using lazy iterators where available... A practical example: good 2.x code will typically use xrange instead of range; xrange was the starting point for the Python 3.x' range implementation (although range is even better in Python 3, since it can handle values larger than sys.maxint).

Above all, it is recommended that you focus on writing good code so that 2.x vs 3.x becomes less of an issue. That includes writing full unit test suites, and getting Unicode right (Python 3.x is significantly less forgiving than 2.x about Unicode versus bytes issues: this is generally considered to be a good thing; it just makes porting some software packages fairly annoying).

I want to use Python 3, but there's this tiny library I want to use that's Python 2.x only. Do I really have to revert to using Python 2 or give up on using that library?

Well, assuming you can't find an alternative package that already supports Python 3, you still have a few options to consider:

The ideal situation is that you try to port the library to 3.x. Oftentimes you'll find someone is already working on this. Even when that's not the case, existing project members will usually appreciate the help, especially as porting often finds bugs in the original software, improving the quality of both the original and the 3.x port. Porting isn't always easy, but it's usually easier than writing your own thing from scratch.

How you're supposed to do porting is explained in PEP 3000. The basic idea is to take the 2.x version of the library and use the automated 2to3 converter to create a Python 3 compatible version and check that all the unit tests still pass. If tests fail, modify the original 2.x sources and try again. This approach makes it feasible to support 2.x and 3.x in parallel from a single 2.x code base. This is much easier than trying to maintain separate 2.x and 3.x branches in parallel (just ask the core Python developers about that one - they've been stuck with doing that for a couple of years now!).

The porting situation is more complicated if there are C extension modules involved, but even then it is still likely to be easier than inventing your own equivalent package.

There are also some more in depth guides right here on the wiki: PortingPythonToPy3k, PortingExtensionModulesToPy3k

I decided to write something in 3.x but now someone wants to use it who only has 2.x. What do I do?

In addition to the 2to3 tool which allows 3.x code to be generated from 2.x source code, there's also the 3to2 tool, which aims to convert 3.x code back to 2.x code. In theory, this should work even better than going the other direction, since 3.x doesn't have as many nasty corner cases for the converter to handle (getting rid of as many of those as possible was one of the main reasons for breaking backward compatibility after all!). However, code which makes heavy use of 3.x only features (such as function annotations or extended tuple unpacking) is unlikely to be converted successfully.

It's probably also fair to say that 3to2 is the road less traveled compared to 2to3 at this stage, so you might come across a few rough edges here and there. However, if you want to write 3.x code, it's definitely an idea worth exploring.

six is another tool.

Other resources that may help make the choice between Python 2 and Python 3

Footnotes

  1. PyGobject is the recommended library for GTK+ programming and it has Python 3 support, but some GNOME specific libraries are yet to be ported. (1)

Unable to edit the page? See the FrontPage for instructions.