This section covers the most important changes in Python 3 from a Django developer's perspective. For the full list of changes, please refer to the recommended reading section at the end of this chapter.

The examples are given in both Python 3 and Python 2. Depending on your installation, all Python 3 commands might need to be changed from python to python3 or python3.4.

In Python 3, the __str__() method is called for string representation of your models rather than the awkward sounding __unicode__() method. This is one of the most evident ways to identify Python 3 ported code:

class Person(models.Model):
    name = models.TextField()

    def __unicode__(self):
        return self.name

class Person(models.Model):
    name = models.TextField()

    def __str__(self):
        return self.name

The preceding table reflects the difference in the way Python 3 treats strings. In Python 2, the human-readable representation of a class can be returned by __str__() (bytes) or __unicode__() (text). However, in Python 3 the readable representation is simply returned by __str__() (text).

Python 2 has two kinds of classes: old-style (classic) and new-style. New-style classes are classes that directly or indirectly inherit from object. Only the new-style classes can use Python's advanced features, such as slots, descriptors, and properties. Many of these are used by Django. However, classes were still old-style by default for compatibility reasons.

In Python 3, the old-style classes don't exist anymore. As seen in the following table, even if you don't explicitly mention any parent classes, the object class will be present as a base. So, all the classes are new-style.

>>> class CoolMixin:
...     pass
>>> CoolMixin.__bases__
() 

>>> class CoolMixin:
...     pass
>>> CoolMixin.__bases__
(<class 'object'>,) 

The simpler call to super(), without any arguments, will save you some typing in Python 3.

class CoolMixin(object):

    def do_it(self):
        return super(CoolMixin, 
                  self).do_it()

class CoolMixin:

    def do_it(self):
        return super().do_it()

Specifying the class name and instance is optional, thereby making your code DRY and less prone to errors while refactoring.

Imagine the following directory structure for a package named app1:

/app1
  /__init__.py
  /models.py
  /tests.py 

Now, in Python 3, let's run the following code in the parent directory of app1:

$ echo "import models" > app1/tests.py
$ python -m app1.tests
Traceback (most recent call last):
   ... omitted ...
ImportError: No module named 'models'
$ echo "from . import models" > app1/tests.py
$ python -m app1.tests
# Successfully imported

Within a package, you should use explicit relative imports while referring to a sibling module. You can omit __init__.py in Python 3, though it is commonly used to identify a package.

In Python 2, you can use import models to successfully import the models.py module. However, it is ambiguous and can accidentally import any other models.py in your Python path. Hence, this is forbidden in Python 3 and discouraged in Python 2 as well.

In Python 3, according to PEP 3333 (amendments to the WSGI standard), we are careful not to mix data coming from or leaving via HTTP, which will be in bytes, as opposed to the text within the framework, which will be native (Unicode) strings.

Essentially, for the HttpRequest and HttpResponse objects:

Unlike Python 2, the strings and bytes are not implicitly converted while performing comparisons or concatenations with each other. Strings mean Unicode strings only.

Exception-handling syntax and functionality has been significantly improved in Python 3.

In Python 3, you cannot use the comma-separated syntax for the except clause. Use the as keyword instead:

try:
  pass
except e, BaseException:
  pass

try:
  pass
except e as BaseException:
  pass

The new syntax is recommended for Python 2 as well.

In Python 3, all the exceptions must be derived (directly or indirectly) from BaseException. In practice, you would create your custom exceptions by deriving from the Exception class.

As a major improvement in error reporting, if an exception occurs while handling an exception, then the entire chain of exceptions are reported:

>>> try:
...   print(undefined)
... except Exception:
...   print(oops)
... 
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  NameError: name 'oops' is not defined

>>> try:
...   print(undefined)
... except Exception:
...   print(oops)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  NameError: name 'undefined' is not defined

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  NameError: name 'oops' is not defined

Once you get used to this feature, you will definitely miss it in Python 2.

The core developers have cleaned up and organized the Python standard library. For instance, SimpleHTTPServer now lives in the http.server module:

$ python -m SimpleHTTP

ServerServing HTTP on 0.0.0.0 port 8000 ...

$python -m http.server

Serving HTTP on 0.0.0.0 port 8000 ...

Python 3 is not just about language fixes. It is also where bleeding-edge Python development happens. This means improvements to the language in terms of syntax, performance, and built-in functionality.

Some of the notable new modules added to Python 3 are as follows:

Even if some of these modules have backports to Python 2, it is more appealing to migrate to Python 3 and leverage them as built-in modules.

$ python -m venv djenv

[djenv] $ source djenv/bin/activate

[djenv] $ pip install django

We cannot possibly fit all the Python 3 changes and improvements in this appendix. However, the other commonly cited changes are as follows: