Last week saw the release of a major revision to the Python language in the form of Python 3.  The 3.0 release comes with a slew of updates to the standard library, changes in syntax and other requested improvements.  If one thing can be said about the 3.0 release, it’s that it is a major step forward for Python and it’s guiding philosophy of “There should be one – and preferably only one – obvious way to do it”.

What’s Different

Much of the cruft that had accumulated over the 2.x releases has been removed, and the language has received a serious amount of well thought out tidying.  Unfortunately, nothing in this world is free, and the exceptional cleanness of Python 3 comes at the cost of backwards compatibility.  Still, the cost appears to be worth the price as the update is less error prone, more internally consistent and easier to maintain.  This greater consistency results in a language that is easier to learn. With whole classes of defects effectively eliminated, Python 3 is a safer bet as well.

A selection of the bigger changes include:

• print is now a function instead of a statement.  Keywords are now used to replace the special syntax of the old statement.  This change makes the language more consistent, but the most significant benefit is that it’s now substantially easier to alter the behavior of print in your code. Here are a couple of examples:

  print "foo" #old
  print("foo") #new
   
  print >>openfile, "bar" #old
  print("bar", file=openfile) #new

• String formatting has likewise received a significant overhaul.  Instead of using the old % syntax for templating strings, the str class now has a format() method.  Format can use positional arguments in the string ( {0}, {1} ) to pull values from a list or a set, but it can also use keywords to fetch values from dictionaries and objects ({0[name]}, {sys.platform} for format(somedict) and format(sys=sys) respectively).
• All strings are Unicode now.  The str class has been replaced with the unicode class.  The bytes class has been introduced to store unencoded data.  Effectively this means that str behaves like unicode used to, and bytes behaves much like str used to.  The biggest difference in the new behavior is that you can now no longer mix the two types, and so you must use str.encode() and bytes.decode().
• long has been renamed to int.  The old int type has been removed.  There is now only one integral type in python.
• Integer division is now true division and returns a float.  3/2 will return 1.5.  Use the 3//2 syntax to get the old behavior of returning 1.
• String exceptions are dead.  All exceptions need to be exception classes that inherit from BaseException or it’s children.  (Though in most cases they should inherit from Exception.)  This means the long transition from Perl-style string exceptions to more Java-style object exceptions is complete.  (As a note, the object exceptions became even more Java-like with exception chaining being added.  The days of Python swallowing exceptions are numbered!)
• Set literals have been added with syntax similar to dictionaries: {1, 2}.
• Dictionaries and sets can now both be created with comprehensions.  A comprehension is like a dict or set literal that uses a function to populate the set or dict instead of declaring specific values.  Example:

  # set comprehension
  {letter.upper() for letter in "foo"}
  {'F', 'O'} #resulting set
   
  # dict comprehension
  {letter: letter.upper() for letter in "foo"}
  {'f': 'F', 'o': 'O'} #resulting dict

• Views and Iterators replace lists in much of the standard library.  dict.keys(), dict.items(), dict.values(), map(), filter() and zip() amongst other functions no longer return lists.  Instead they return views or iterators.  This change prevents a whole group of possible hard to detect defects that come from people depending on the order of values returned from these functions.  Each of these more properly returns an unordered set or an iterator instead of a list.

There are many other more minor changes as well, mostly involving the removal of parts of the language that should no longer be used such as old style classes. A few other highlights include the removal of <> in favor of != for inequality, dropping dict.has_key(foo) in favor of foo in dict and the addition of function annotations to unify how various IDEs can do some level of type checking.

Porting Your Code and the Value of Python 2.6

Many of the changes for 3.0 have been previewed in the simultaneously developed release 2.6.  Version 2.6 is not just a new release in the 2.x series, it is also a fantastic tool for assisting in the migration of code from 2.x to 3.x.  Some changes – such as string formatting – were backported fully to 2.6, and many other features – such as the print function – are available to import from __future__ for use in your 2.6 code today.  Finally, the tool 2to3 will automate most of the process of porting code from 2.6 to 3.0.  Reports so far are that most code can be made to work in 2.6 and automatically translated to 3.0 with a relative minimum of fuss.  As a note, the Python maintainers suggest that as long as a project wants to maintain both 2.x and 3.x sources, they should maintain the 2.x code, and use the code generated by 2to3 unmodified (with bugfixes to the 3.x code implemented in the 2.x sources).

What Does It Mean?

Python 3.0 has done a lot to keep the language’s syntax clear, clean and obvious, but that doesn’t mean anything if you don’t have the libraries you need.  Python 3.0 can be thought of as more of a transitional release then something targeted at the average developer.  For the average developer to find it useful, the libraries need to get ported first.  Until frameworks such as Django and libraries like Twisted are ported to the new syntax, likely most of us won’t find ourselves coding on a release past 2.6. Version 3.0 is a well done introduction to the new language syntax, but it’s really a release intended for the maintainers of popular Python libraries and frameworks so that they can get their offerings up and running for future releases like 3.1. or 3.2.  This should give the 3.0 code a chance to become rock solid and as fast as the 2.6 branch before we all make the leap (3.0 is purportedly about 10% slower then 2.6, but the C code is as yet unoptimized).  Python has taken a great step forward, but it will still be a year or two before the rest of us can take that step with it.

Dig Deeper

Find out about all the changes in the Python 3.0 changelog.  You can also read about many of the transitional features in the Python 2.6 changelog.