Revision 2 as of 2010-06-21 11:56:04

Clear message

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

NOTE: This page is a work in progress, based on the version the #python folks put together for their own needs (see link at the end). Editors feel free to drop this notice once the content has matured a bit

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 (20 Jun 2010), both are still under development. There's at least one more 2.x release planned (2.7), but the 2.x branch probably won't see any new major releases after that. 3.x is under active and continued development.

3.x is the newest branch of Python. People decided to clean up Python 2.x properly, with less regard for backwards compatibility than new releases in the 2.x range. Nick Efford has a nice writeup about why you might like Python 3.x as a language here: http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html.

Python has amassed a pretty big 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 what should I pick?

What you ought to pick is mostly dependant 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 library support and current Linux distributions and Macs still shipping with 2.x by 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 might only be developing something for themselves) and you're writing things where lack of third party software isn't a major impediment, Python 3.x is an excellent choice.

Most of the current #python regulars will recommend Python 2.x because a lot of libraries that make your life easier only work on 2.x so far. Popular ones include Twisted (for networking and a bunch of other stuff), gevent (like Twisted but different), Django (for building websites), PyGTK (for making GUIs), py2exe (for packaging your application for Windows users), PIL (for processing images), numpy (for number crunching)...

Most of these libraries have people working on 3.x support and it's mostly a work in progress in various stages of completion. numpy, for example, is pretty close to completion. For some libraries, it's more of a priority than others: Twisted, for example, is mostly focused on production servers, where people are often using old versions of 2.x, let alone thinking about 3.x.

One of the problems with picking 3.x stuff is that most of the regulars are professional 2.x developers, so we might not be able to help as effectively with questions about new 3.x software as opposed to exisitng 2.x software such as Twisted, PIL or PyGTK.

So 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.x have been backported to 2.x. The 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. Examples include an ordered dict (which might be coming to 2.7), and the "nonlocal" keyword, which probably won't be coming to 2.x (but you can work around that, and it's not really a feature you'll need every day). You might start seeing a few libraries here and there that use 3.x, but most of the time they'll have 2.x versions too.

Good 2.x code will behave a lot like new 3.x code. That can mean a lot of things, including using new-style classes, not using ancient deprecated arcane incantations of print, lazy iterators where available...

#python will always above all recommend 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 less forgiving about unicode versus bytes: this is generally considered to be a very good thing; it just makes porting software that doesn't make the distinction very well 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?

First things first, and I can't stress this enough: please don't start implementing your own thing. This is called NIH (Not Invented Here) syndrome and it has produced a lot of bad software. Please, please, go help an existing project if it exists, they'll be glad to see people helping, they can assist you with questions, and your work benefits the entire Python community as a whole.

Anyway, you don't have to use Python 2.x. You could also make the Python 3.x vs 2.x situation better by porting an existing library and making future users happy. Porting isn't always easy, but it's usually easier than writing your own thing from scratch. Existing project members will love you, because porting often finds bugs in the original software, improving the quality of both the original and the 3.x port.

How you're supposed to do porting is explained in PEP3000: http://www.python.org/dev/peps/pep-3000/#id9.

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

There's also the 3to2 tool, which tries it's best to convert 3.x code back to 2.x code.

Other Resources Discussing the Pros and Cons of Python 2 and Python 3

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