What does Python 3.0 mean for you?
The long-awaited release of Python 3.0 came on December 3, 2008. This is a big step forward in the evolution of Python, as it provides an opportunity for the core developers to introduce backwards-incompatible changes to the language and libraries and break free of some past design decisions that have been deemed misguided or short-sighted.
The precise nature of the changes in Python 3.0 may not be clear to anyone who hasn’t been following the progress of the release over the last couple of years, and that seems to be causing consternation in some parts of the community. There is no reason for alarm because support for 2.x is not being dropped. While having separate, somewhat incompatible, versions of the interpreter will cause some confusion, it was always (and is still) the plan to support both versions until enough code is ported to make dropping support for 2.x realistic. That is expected to take several years.
It has been no secret that Guido and some of the other core developers have wanted to make a variety of backwards-incompatible changes for some time. Guido has been talking publicly about Python 3000 for 8 years. That’s at least two lifetimes in internet time! All of the plans were discussed at length, in public, on the python-dev and python-3000 mailing lists. PEPs were written and reviewed, and all of the code has been available in the branch for some time. With the actual release announcement, however, some people seem surprised to find that they actually went through with the changes.
Failure to change means we stagnate, and stagnation leads to obsolescence. The differences in 3.0 are necessary to keep the language vibrant and growing. The benefits include changing the methods on built-in types so they consistently return iterable “views” instead of list objects; simplification of comparison overloading; removing surprises by making integer division return floating point results when appropriate; making Unicode the default for text strings; function argument and return value type annotation; set and dictionary comprehensions (like list comprehensions, but for sets and dictionaries); and basic clean-up of dusty or crufty “corners” of the language or standard library such as changing some module names to follow the PEP 8 conventions.
Failure to change means we stagnate, and stagnation leads to obsolescence.
By the time you read this, 3.0 will have been out for at least a month and it is quite possible that the 3.0.1 will have been released. Some developers have begun to release updates to their libraries enabling them to work under 3.0, and I’m sure more porting is ongoing. We have not reached a critical mass, so most of the community will not be ready to move up, but we are making progress. One important step, already being implemented, is for platform vendors to include 3.x in their operating system updates so that developers have easy access to it.
If you have libraries of your own to port, there are several resources to help out. First, study the release notes and list of updates to understand what has changed. Join the python-porting mailing list and participate in discussions with other developers encountering some of the same challenges you might see in your porting effort. Check out 2to3, the tool for applying some of the more common transformations to your Python code automatically. And of course, Python Magazine will be covering some of the differences between 2.x and 3.x over the course of the next few months.
The move from 2.x to 3.x is going to take a considerable amount of time for most users, and that is anticipated. While you should start planning to upgrade, you should not rush out to move all of your applications to 3.0 right away. There is every expectation, from the core developers and most of the community, that the 2.x branch will be supported for several years as we work on the migration.
New Columnists
As hinted in my last column, the new year brings changes for Python Magazine, too. Beginning this month, we are proud to present the column, Ask the Pragmatic Testers, written by Titus Brown and Grig Gheorghiu. Many of you will recognize Titus and Grig from the large and growing Python testing community. Both have a wealth of development experience, and we’re excited to add them as regular contributors to the magazine. They start their series by explaining the benefits of testing as a way to manage the complexity of software development. It’s a convincing argument for adding automated tests to your project, no matter the size. Code has a way of growing over time, so even small projects benefit by starting with automated tests right from the beginning.
As the title of the column implies, Titus and Grig want to hear from you. What sorts of testing are you doing, and what problems are you encountering? What aspects of testing are most interesting to you? Email your questions or suggestions for them to pragmatictesters at pythonmagazine dot com.
If you have comments, criticisms, or ideas for topics we should cover elsewhere in the magazine over the next year send them to me at doug dot hellmann at pythonmagazine dot com.