Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Python 3.0 Breaks with the Past

Python 3.0 Breaks with the Past

Leia em Português

This item in japanese

Python 3.0 (aka Python 3000) was finally released 3 months ago (December 3rd 2008). It has been almost 9 year since Guido van Rossum, the language’s author, envisioned this new and revolutionary Python version. Python 3.0 breaks the backward compatibility with previous versions of the language.

In a blog entry from 2007, Guido wrote about how Python 3.0 was conceived:

For a long time there wasn't much more than a list of regrets and flaws that were impossible to fix without breaking backwards compatibility. The idea was that Python 3000 would be the first Python release to give up backwards compatibility in favor of making it the best language going forward.

In an interview, Guido described what happened afterword:

I started the actual effort to do something about it -- to actually design it and agree on everything -- about three years ago, just around the time I started here at Google when I got more time for Python. For a long time I've been really pushing the project along, getting a lot of people excited. I gave yearly talks at PyCon, at Euro Python, other conferences. Over the last 12 months, I've been not entirely but for a large part just been sitting back and enjoying the ride while the developer community was finishing up all of the final details and getting ready for the release.

Since Python 3.0 breaks backwards compatibility with Python 2.x its release was coordinated with the release of Python version 2.6 that provides a convenient and safe way to experiment with much of the new features. As was done in previous Python versions, the 2.6 version is fully compatible with earlier versions but also contains many of the new stuff from Python 3.0 (some of it available by using the ingenious "from __future__ import" statement).

Python 3.0 new features

Guido said the standout features in Python 3.0 are, "Much better Unicode support, and cleanup of collected 'cruft'". And indeed full unicode support is one of the main aspects that have changed. Guido wrote:

All text is Unicode; however, encoded Unicode is represented as binary data ... As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change. The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text.

While Python 2.x did support Unicode, there was both an (old) str type and (new) unicode type. In Python 3.0 all strings are unicode (str is now unicode string) and there is a new type called bytes to hold byte sequences.

Other changes in Python 3.0 include:

  • Print is a function - The print statement has been replaced with a print() function, with keyword arguments to replace most of the special syntax of the old print statement (one can experiment with this feature in Python 2.6 by using from __future__ import print_function. More on this in PEP 3105 -- Make print a function.
  • Views And Iterators Instead Of Lists - Some well-known APIs no longer return lists. dict.iterkeys(), dict.itervalues(), anddict.iteritems() methods in dictionaries where removed. Instead, you can use .keys(), .values(), and .items(), which have been revamped to return lightweight, set-like container objects instead of a list which is a copy of the keys or values. The advantage here is the ability to perform set operations on keys and items without having to copy them.
  • Integers - remove the ambiguity of the division operator ('/') by always returning a float. In previous versions it returned the floor of the mathematical result of division if the arguments were ints or longs, but it returned a reasonable approximation of the division result if the arguments were floats or complex. This feature can be used in version 2.6 by using from __future__ import division. More on this in PEP 238 -- Changing the Division Operator.
  • Various syntax changes

A lot of thought was invested on making the transition to version 3.0 as easy as possible. In addition to the backports of many features into version 2.6, there is a new command-line switch that enables warnings about features that will be removed in Python 3.0. You can run code with this switch to see how much work will be necessary to port code to 3.0. Moreover, a new tool called "2to3" which is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code. Guido also added:

Actually, the two-to-three tool has a mode where instead of modifying the code in place, what it normally does, you can also ask it to just print out unified diffs of what's going to change. If you want to, you can just review it on a file-by-file basis and decide, "Oh, yeah. It's doing the right thing." Or if you review it carefully, you might find that there's actually a case where the tool is not doing the right thing. You can then take that patch file and manually redo the patch that you think should be applied. That way the tool can still help you with the bulk of the work. That was a precedent for what's happening in the Python 2.6 to 3.0 world.

Should someone develop in Python 2.6 or 3.0? Guido made this observation:

... it's a very personal choice to decide whether to use 3.0 or 2.6. You don't run the risk of being left behind by taking a conservative stance at this point. 2.6 will be just as well supported by the same group of core Python developers as 3.0. At the same time, we're also not sort of deemphasizing the importance and quality of 3.0. So if you are not held back by external requirements like dependencies on packages or third party software that hasn't been ported to 3.0 yet or working in an environment where everyone else is using another version.

One of the best known aspects of Python and the Python community is the conservative advancements from version to version with great concern for backwards compatibility. Now the Python community has shown that it can do what others only dream about - to produce a better version of the language at the cost of backwards compatibility. The Java community as been playing with this idea for years but since version 1.2 (aka Java 2) the "bad and ugly" were not touched in fear of breaking existing code.

Rate this Article