Migration to Python 3.0
There are three different "flavors" of migration you should consider:
- Start using Python 3.0 for new projects.
- Port existing projects to Python 3.0.
- Support both Python 2.x and 3.0 in your projects.
In addition, you should take these important factors into account:
- How critical is your project?
- What is the skill level of the developers?
- What is the lifespan of your project?
To make an informed decision, you need to have a pretty good grasp of the following:
- The current status of Python 3.0
- The Python 3.0 porting status of third-party packages you use or depend on
- Python 3.0 tool support
- Python 3.0 books
- Python 3.0 community support
- The future of Python 3.x
- Roadmap of Python 3 itself
- Roadmap of Python 3 support of third-party packages
- Roadmap of Python 3 tools
- The future of Python 2.x
That's a lot to consider, but this article will give you solid information and guidelines.
I'll begin with Python 3 itself. The final release of Python 3.0 occurred on December 3, 2008, followed by a bug fix release (Python 3.01) on February 13, 2009. Python 3.0 is still in bug fix mode, so no new features will be added until Python 3.1. My own experience with Python 3.0 was very positive and I didn't run into any bugs; however, Python 3 had very little field testing, so there might be bugs lurking in the parts of the language or (more likely) the standard library that impact your application. In addition, Python 3's performance has a lot of room for improvement; overall, it's slower than Python 2.
Python 3.1 has been released on June 27, 2009 exactly on schedule (according to the release schedule of PEP-375. Python 3.1 includes these main features and additions:
- io rewritten in C
- A reworked email package
- An IP Address library added to stdlib
- Update simplejson to the latest external version
- An ordered dictionary collections class
- A fix for contextlib.nested()
- Auto-numbered replacement fields in str.format() strings
- An upgraded xml.etree to the latest external version
- The ability to nest with statements
As you can see, it's a pretty low-key release. Rewriting the io module in C will probably improve the performance of I/O-bound applications. Python 3.1's main purpose is to serve as a kind of a service pack for Python 3.0, which is why it will appear only seven months after Python 3.0. Python 3.2 will probably be released 18 to 24 months later, which is a more typical release rate for minor versions. See this blog for a better analysis. The release schedule for Python 2.7 is not finalized yet, but the idea is that it will follow the Python 3 development cycle closely, so it will be probably be released around the time Python 3.2 is released—again, it will serve as a migration step from Python 2 to Python 3.
The schedule for Python itself seems pretty predictable (especially given Python's unusual track record of delivering on time). But the picture for third-party packages is not as clear. As you will see later in this article, it's usually pretty straightforward to port a Python 2 codebase to Python 3—especially if the Python 2 code uses modern idioms. However, many sophisticated Python packages depend on other Python packages and/or C extension modules. In such cases you won't be able to port upstream packages until all the dependencies have been ported as well. This means that packages with deep dependency graphs might have to wait a long time until all their dependencies have been ported.
At PyCon 2009 in Chicago Guido Van Rossum commented on the porting question. He believes that most major packages will have been ported to Python 3 by the next PyCon (March 2010), which is probably a very good estimate. By the time of Python 3.1's release, a lot of people will be using it, so there will be a lot of grass-roots pressure on the main third-party package developers to port their packages. Many package developers have already taken initial steps in this direction, as you can see by the Python 3 packages listed on the Python Package Index.
Note that among the important third-party packages still missing are: Numpy, PIL, wxPython, Twisted, and TurboGears.
There is a chicken and an egg problem here. The porting effort for big, mature packages and frameworks could be substantial. It is often not cost-effective for package developers to port immediately to Python 3 unless their users demand it. In fact, they actually benefit from waiting, both because they don't have to maintain another port and because the porting tools and practices will get better over time. In addition, frameworks built on top of many other packages (such as TurboGears) must wait until their dependencies have been ported.
Python 3 Books, Tools, and Support
There are already several Python 3 books. Most successful Python books will get a new Python 3 edition. The list may grow by the time you read this article. If you are a seasoned Python 2 programmer I recommend the online Dive into Python 3 by Mark Pilgrim. This is an incomplete work in progress, but it has an informal and accessible writing style.
The tool support situation is not as bright. As far as I can tell, no Python development environment fully supports Python 3 yet. I use Komodo as my main Python IDE. I particularly like its debugger and it definitely irks me that I can't use it for Python 3 coding.
Community support is always available on the mailing lists, and is bound to get better as more people move to Python 3 and run into your problem before you do and write about it.
With that information in hand, here are some concrete guidelines regarding the timing of migration. I recommend starting with or porting to Python 3 immediately if:
- You are a newcomer that wants to learn Python for fun (and maybe profit in the future). You should read and start a little project of your own in Python 3.
- You are a seasoned Python 2 programmer that wants to learn what's up with Python 3. You should read, start a little project of your own in Python 3 and also port a little Python 2 project.
- You are an open source developer that wants to support Python 3 developers.
In contrast, I recommend staying with Python 2 for now if:
- You are responsible for an important project based on Python 2.
- You have a tight schedule.
- Your project is in maintenance only mode.
If you are unsure whether you should pick up Python 3 or stay with Python 2, stay with Python 2. However, if you do decide to stay with Python 2, I recommend porting to Python 2.6 if you can spare the cycles. That release includes many valuable additions and changes, and you will be ready for Python 3 migration when it's appropriate. It should be painless.