What's new in Python 3

The Next Snake

© Eric Isselée, 123RF

© Eric Isselée, 123RF

Author(s):

What do Python 2.x programmers need to know about Python 3?

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.

Listing 1

Overloading the Print Function

01 import sys
02 def print(*args,sep='',end="\n",file=sys.stdout):
03   __builtins__.print(*args)
04   __builtins__.print(*args,file=open("log.file","a"))

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.

Read full article as PDF:

042-045_python.pdf (408.84 kB)

Related content

  • Optimizing Python

    The trick to optimization is to save time in the right places.

  • Boo

    Hooked on Python's "wrist-friendly" syntax? Enamored of .NET architecture but equally appreciative of C#'s strong typing? Boo offers the best of three worlds.

  • Dotnet Scripting with Boo

    Boo is a scripting language tailor-made for Mono and .NET. This haunting mixture of Python and C# may be just what you need to get started with the .NET framework.

  • Workspace: EasyGUI

    If you need to add graphical elements to Python script, EasyGUI can help beginners and experts alike.

  • Practical Python in Linux

    We’ll introduce you to Python, an easy-to-learn scripting language, and also help you get started creating your own practical Python scripts.

Comments

  • It is not named as snake, but you missed the point

    The title of the article does not have anything to do with what inspired or not the creator of this language. The above comment just demonstrates the most ridiculous and basic lacking of any creativity or humor and denotes a very primitive and intolerant mind, which does not seem to even have noticed that the logo of Python is that of a SNAKE and not exactly a picture of Monty Python.

    The article is very good.

    Sadly, for some people it is easier to destroy and insult than to be creative and positive about anything.
  • Ancestor python

    Yeah so what if it was not named after a snake. Monty Python's ancestors derived their surname from the python snake itself which was commonly found in their area where they originated from; so it's still from the snake. Heh heh!
  • Python is not named after a snake

    It's hard to imagine how the author could get this so fundamentally wrong. Hear this: Python is not named after the snake; it's named after Monty Python, as any cursory survey of its history will reveal.
comments powered by Disqus

Direct Download

Read full article as PDF:

042-045_python.pdf (408.84 kB)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia