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:
printis 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
strclass now has aformat()method. Format can use positional arguments in the string ({0},{1}) to pull values from alistor aset, but it can also use keywords to fetch values from dictionaries and objects ({0[name]},{sys.platform}forformat(somedict)andformat(sys=sys)respectively). - All strings are Unicode now. The
strclass has been replaced with theunicodeclass. Thebytesclass has been introduced to store unencoded data. Effectively this means thatstrbehaves likeunicodeused to, andbytesbehaves much likestrused to. The biggest difference in the new behavior is that you can now no longer mix the two types, and so you must usestr.encode()andbytes.decode(). longhas been renamed toint. The oldinttype has been removed. There is now only one integral type in python.- Integer division is now true division and returns a float.
3/2will return 1.5. Use the3//2syntax to get the old behavior of returning 1. - String exceptions are dead. All exceptions need to be exception classes that inherit from
BaseExceptionor it’s children. (Though in most cases they should inherit fromException.) 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
dictorsetliteral that uses a function to populate thesetordictinstead 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()andzip()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 unorderedsetor aniteratorinstead of alist.
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.
[...] Last friday I was approached by Wazi to write an article about the release of Python 3. Go take a gander: Python takes a great step forward: Python 3 [...]
Good read, thanks for the quick and dirty!
nice post! I like the set and dictionary comprehension