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
. 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

By the time you read this, 3.0 will have been out for at least a
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.

Originally published in Python Magazine Volume 3 Issue 1 , January, 2009