The Next Snake

With the latest major Python release, creator Guido van Rossum saw the opportunity to tidy up his famous scripting language. What is different about Python 3.0? In this article, I offer some highlights for Python programmers who are thinking about making the switch to 3.x.

The first important point is that version 3.0, which is also known as Python 3000 or Py3k, broke with an old tradition in that it is not downwardly compatible. According to von Rossum, "There is no requirement that Python 2.6 code will run unmodified on Python 3.0."

Python 2.6's main purpose is to take the pain out of switching versions. Many of Python 3.0's features were backported to Python 2.6. (A similar Python 2.7 version will accompany the recent Python 3.1 release.) In addition to these transitional 2.x versions, the 2to3 command-line tool supports programmers migrating code from Python 2.x to Python 3.x.

Quirks

Python has some quirks that have bugged van Rossum since the beginning of the millennium. With Python 3, he decided to sacrifice downward compatibility to remove these obstacles. The most blatant break with Python 2 is the syntactic change to print, which has mutated from a statement to a function; thus, parameters, now called keywords, are called in parentheses. This change is in line with Tim Peters' The Zen of Python: "Explicit is better than implicit." [1]. The new generic print syntax is print(*args, sep=' ', end='\n', file=sys.stdout), where args are the arguments, sep is the separator between the arguments, end is the end-of-line character, and file is the output medium.

Table 1 lists the syntax changes to the print function, including their default values. The advantage of the new version is not apparent until you take a closer look; the new print function now supports overloading. Listing 1 shows a print function that writes to standard output and to a logfile at the same time. To allow this to happen, the function instrumentalizes the built-in __builtins__.print function.

Doing no more than absolutely necessary is a virtue in many programming languages. Python 3 puts far more emphasis on lazy evaluation. Lists, dictionaries, or Python's functional building blocks no longer generate complete lists; they add just enough to support the evaluation of the output. Lazy evaluation thus saves memory and time.

The Python interpreter achieves this effect by returning only one iterable context that generates values on request. (This was what distinguished range and xrange in Python 2.) In Python 3, range acts like xrange, thus making the xrange function redundant.

The same applies to the functional building blocks map, filter, and zip. These functions have been replaced by their equivalents from the itertools library. For dictionaries, the resulting, iterable contexts are known as views. However, if the programmer needs the full expanded list, simple encapsulation of the iterable context by means of a list constructor, as shown in the following example, can help: list(range(11)) produces [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10].

Division

That 1/2 == 0 shocks Python newcomers. This unusual feature is attributable to Python's C roots. Python 3 gets rid of this strange effect by differentiating between true division and floor division. Whereas in true division 1/2 == 0.5, floor division works like division in Python 2. The notation for floor division uses two slashes: 1//2 == 0.

In Python 2, programmers had to declare strings explicitly as Unicode strings. Python 3 strings are now implicitly Unicode. Python 3.0 only distinguishes between text and data. Text (str) relates to strings and is the same as Python 2 Unicode strings. Data (bytes) are 8-bit strings and the same as Python 2 strings. Python 3 developers need to declare data: b"8_bit_string". Table 2 gives an overview of the difference between Python 2 and 3.

The str.encode() and bytes.decode() functions are available to convert between data types. Programmers need this conversion in Python 3.0 when working with both data types; implicit type conversion no longer takes place. Programmers simply have to decide.

Syntactic Changes

Function annotations in Python 3 now allow programmers to bind metadata to a function. Decorators can then be added to the function in a second step; decorators automatically generate data from the metadata or perform type checking at run time.

The equivalent functions, sumOrig and sumMeta (Figure 1), show function declarations with and without metadata. The second function includes metadata for the signature and return value. This metadata can be referenced with the __annotations__ function attribute.

Figure 1: Function annotations bind metadata to a function.