What’s New in This Chapter

There are no new Python features related to the subject of this chapter, but I heavily edited it based on feedback from technical reviewers of the second edition, especially Leonardo Rochael and Caleb Hattingh.

I wrote a new opening section focusing on the super() built-in function, and changed the examples in “Multiple Inheritance and Method Resolution Order” for a deeper exploration of how super() works to support cooperative multiple inheritance.

“Mixin Classes” is also new. “Multiple Inheritance in the Real World” was reorganized and covers simpler mixin examples from the standard library, before the complex Django and the complicated Tkinter hierarchies.

As the chapter title suggests, the caveats of inheritance have always been one of the main themes of this chapter. But more and more developers consider it so problematic that I’ve added a couple of paragraphs about avoiding inheritance to the end of “Chapter Summary” and “Further Reading”.

We’ll start with an overview of the mysterious super() function.

The super() Function

Consistent use the of the super() built-in function is essential for maintainable object-oriented Python programs.

When a subclass overrides a method of a superclass, the overriding method usually needs to call the corresponding method of the superclass. Here’s the recommended way to do it, from an example in the collections module documentation, section “OrderedDict Examples and Recipes”:²

class LastUpdatedOrderedDict(OrderedDict):
    """Store items in the order they were last updated"""

    def __setitem__(self, key, value):
        super().__setitem__(key, value)
        self.move_to_end(key)

To do its job, LastUpdatedOrderedDict overrides __setitem__ to:

1. Use super().__setitem__ to call that method on the superclass, to let it insert or update the key/value pair.

2. Call self.move_to_end to ensure the updated key is in the last position.

Invoking an overridden __init__ method is particularly important to allow superclasses to do their part in initializing the instance.

    def __init__(self, a, b) :
        super().__init__(a, b)
        ...  # more initialization code

You may have seen code that doesn’t use super(), but instead calls the method directly on the superclass, like this:

class NotRecommended(OrderedDict):
    """This is a counter example!"""

    def __setitem__(self, key, value):
        OrderedDict.__setitem__(self, key, value)
        self.move_to_end(key)

This alternative works in this particular case, but is not recommended for two reasons. First, it hardcodes the base class. The name OrderedDict appears in the class statement and also inside __setitem__. If in the future someone changes the class statement to change the base class or add another one, they may forget to update the body of __setitem__, introducing a bug.

The second reason is that super implements logic to handle class hierarchies with multiple inheritance. We’ll come back to that in “Multiple Inheritance and Method Resolution Order”. To conclude this refresher about super, it is useful to review how we had to call it in Python 2, because the old signature with two arguments is revealing:

class LastUpdatedOrderedDict(OrderedDict):
    """This code works in Python 2 and Python 3"""

    def __setitem__(self, key, value):
        super(LastUpdatedOrderedDict, self).__setitem__(key, value)
        self.move_to_end(key)

Both arguments of super are now optional. The Python 3 bytecode compiler automatically provides them by inspecting the surrounding context when super() is invoked in a method. The arguments are:

type

The start of the search path for the superclass implementing the desired method. By default, it is the class that owns the method where the super() call appears.

object_or_type

The object (for instance method calls) or class (for class method calls) to be the receiver of the method call. By default, it is self if the super() call happens in an instance method.

Whether you or the compiler provides those arguments, the super() call returns a dynamic proxy object that finds a method (such as __setitem__ in the example) in a superclass of the type parameter, and binds it to the object_or_type, so that we don’t need to pass the receiver (self) explicitly when invoking the method.

In Python 3, you can still explicitly provide the first and second arguments to super().³ But they are needed only in special cases, such as skipping over part of the MRO for testing or debugging, or for working around undesired behavior in a superclass.

Now let’s discuss the caveats when subclassing built-in types.

It was not possible to subclass built-in types such as list or dict in the earliest versions of Python. Since Python 2.2, it’s possible, but there is a major caveat: the code of the built-ins (written in C) usually does not call methods overridden by user-defined classes. A good short description of the problem is in the documentation for PyPy, in the “Differences between PyPy and CPython” section, “Subclasses of built-in types”:

Officially, CPython has no rule at all for when exactly overridden method of subclasses of built-in types get implicitly called or not. As an approximation, these methods are never called by other built-in methods of the same object. For example, an overridden __getitem__() in a subclass of dict will not be called by e.g. the built-in get() method.

Example 14-1 illustrates the problem.

>>> class DoppelDict(dict):
...     def __setitem__(self, key, value):
...         super().__setitem__(key, [value] * 2)  
...
>>> dd = DoppelDict(one=1)  
>>> dd
{'one': 1}
>>> dd['two'] = 2  
>>> dd
{'one': 1, 'two': [2, 2]}
>>> dd.update(three=3)  
>>> dd
{'three': 3, 'one': 1, 'two': [2, 2]}

DoppelDict.__setitem__ duplicates values when storing (for no good reason, just to have a visible effect). It works by delegating to the superclass.

The __init__ method inherited from dict clearly ignored that __setitem__ was overridden: the value of 'one' is not duplicated.

The [] operator calls our __setitem__ and works as expected: 'two' maps to the duplicated value [2, 2].

The update method from dict does not use our version of __setitem__ either: the value of 'three' was not duplicated.

This built-in behavior is a violation of a basic rule of object-oriented programming: the search for methods should always start from the class of the receiver (self), even when the call happens inside a method implemented in a superclass. This is what is called “late binding,” which Alan Kay—of Smalltalk fame—considers a key feature of object-oriented programming: in any call of the form x.method(), the exact method to be called must be determined at runtime, based on the class of the receiver x.⁴ This sad state of affairs contributes to the issues we saw in “Inconsistent Usage of __missing__ in the Standard Library”.

The problem is not limited to calls within an instance—whether self.get() calls self.__getitem__()—but also happens with overridden methods of other classes that should be called by the built-in methods. Example 14-2 is adapted from the PyPy documentation.

>>> class AnswerDict(dict):
...     def __getitem__(self, key):  
...         return 42
...
>>> ad = AnswerDict(a='foo')  
>>> ad['a']  
42
>>> d = {}
>>> d.update(ad)  
>>> d['a']  
'foo'
>>> d
{'a': 'foo'}

AnswerDict.__getitem__ always returns 42, no matter what the key.

ad is an AnswerDict loaded with the key-value pair ('a', 'foo').

ad['a'] returns 42, as expected.

d is an instance of plain dict, which we update with ad.

The dict.update method ignored our AnswerDict.__getitem__.

If you subclass collections.UserDict instead of dict, the issues exposed in Examples 14-1 and 14-2 are both fixed. See Example 14-3.

>>> import collections
>>>
>>> class DoppelDict2(collections.UserDict):
...     def __setitem__(self, key, value):
...         super().__setitem__(key, [value] * 2)
...
>>> dd = DoppelDict2(one=1)
>>> dd
{'one': [1, 1]}
>>> dd['two'] = 2
>>> dd
{'two': [2, 2], 'one': [1, 1]}
>>> dd.update(three=3)
>>> dd
{'two': [2, 2], 'three': [3, 3], 'one': [1, 1]}
>>>
>>> class AnswerDict2(collections.UserDict):
...     def __getitem__(self, key):
...         return 42
...
>>> ad = AnswerDict2(a='foo')
>>> ad['a']
42
>>> d = {}
>>> d.update(ad)
>>> d['a']
42
>>> d
{'a': 42}

As an experiment to measure the extra work required to subclass a built-in, I rewrote the StrKeyDict class from Example 3-9 to subclass dict instead of UserDict. In order to make it pass the same suite of tests, I had to implement __init__, get, and update because the versions inherited from dict refused to cooperate with the overridden __missing__, __contains__, and __setitem__. The UserDict subclass from Example 3-9 has 16 lines, while the experimental dict subclass ended up with 33 lines.⁵

To be clear: this section covered an issue that applies only to method delegation within the C language code of the built-in types, and only affects classes derived directly from those types. If you subclass a base class coded in Python, such as UserDict or MutableMapping, you will not be troubled by this.⁶

Now let’s focus on an issue that arises with multiple inheritance: if a class has two superclasses, how does Python decide which attribute to use when we call super().attr, but both superclasses have an attribute with that name?

Any language implementing multiple inheritance needs to deal with potential naming conflicts when superclasses implement a method by the same name. This is called the “diamond problem,” illustrated in Figure 14-1 and Example 14-4.

Figure 14-1. Left: Activation sequence for the leaf1.ping() call. Right: Activation sequence for the leaf1.pong() call.

class Root:  
    def ping(self):
        print(f'{self}.ping() in Root')

    def pong(self):
        print(f'{self}.pong() in Root')

    def __repr__(self):
        cls_name = type(self).__name__
        return f'<instance of {cls_name}>'


class A(Root):  
    def ping(self):
        print(f'{self}.ping() in A')
        super().ping()

    def pong(self):
        print(f'{self}.pong() in A')
        super().pong()


class B(Root):  
    def ping(self):
        print(f'{self}.ping() in B')
        super().ping()

    def pong(self):
        print(f'{self}.pong() in B')


class Leaf(A, B):  
    def ping(self):
        print(f'{self}.ping() in Leaf')
        super().ping()

Root provides ping, pong, and __repr__ to make the output easier to read.

The ping and pong methods in class A both call super().

Only the ping method in class B calls super().

Class Leaf implements only ping, and it calls super().

Now let’s see the effect of calling the ping and pong methods on an instance of Leaf (Example 14-5).

    >>> leaf1 = Leaf()  
    >>> leaf1.ping()    
    <instance of Leaf>.ping() in Leaf
    <instance of Leaf>.ping() in A
    <instance of Leaf>.ping() in B
    <instance of Leaf>.ping() in Root

    >>> leaf1.pong()   
    <instance of Leaf>.pong() in A
    <instance of Leaf>.pong() in B

leaf1 is an instance of Leaf.

Calling leaf1.ping() activates the ping methods in Leaf, A, B, and Root, because the ping methods in the first three classes call super().ping().

Calling leaf1.pong() activates pong in A via inheritance, which then calls super.pong(), activating B.pong.

The activation sequences shown in Example 14-5 and Figure 14-1 are determined by two factors:

• The method resolution order of the Leaf class.

• The use of super() in each method.

Every class has an attribute called __mro__ holding a tuple of references to the superclasses in method resolution order, from the current class all the way to the object class.⁷ For the Leaf class, this is the __mro__:

>>> Leaf.__mro__  # doctest:+NORMALIZE_WHITESPACE
    (<class 'diamond1.Leaf'>, <class 'diamond1.A'>, <class 'diamond1.B'>,
     <class 'diamond1.Root'>, <class 'object'>)

The MRO only determines the activation order, but whether a particular method will be activated in each of the classes depends on whether each implementation calls super() or not.

Consider the experiment with the pong method. The Leaf class does not override it, therefore calling leaf1.pong() activates the implementation in the next class of Leaf.__mro__: the A class. Method A.pong calls super().pong(). The B class is next in the MRO, therefore B.pong is activated. But that method doesn’t call super().pong(), so the activation sequence ends here.

The MRO takes into account not only the inheritance graph but also the order in which superclasses are listed in a subclass declaration. In other words, if in diamond.py (Example 14-4) the Leaf class was declared as Leaf(B, A), then class B would appear before A in Leaf.__mro__. This would affect the activation order of the ping methods, and would also cause leaf1.pong() to activate B.pong via inheritance, but A.pong and Root.pong would never run, because B.pong doesn’t call super().

When a method calls super(), it is a cooperative method. Cooperative methods enable cooperative multiple inheritance. These terms are intentional: in order to work, multiple inheritance in Python requires the active cooperation of the methods involved. In the B class, ping cooperates, but pong does not.

Cooperative methods must have compatible signatures, because you never know whether A.ping will be called before or after B.ping. The activation sequence depends on the order of A and B in the declaration of each subclass that inherits from both.

Python is a dynamic language, so the interaction of super() with the MRO is also dynamic. Example 14-6 shows a surprising result of this dynamic behavior.

from diamond import A  

class U():  
    def ping(self):
        print(f'{self}.ping() in U')
        super().ping()  

class LeafUA(U, A):  
    def ping(self):
        print(f'{self}.ping() in LeafUA')
        super().ping()

Class A comes from diamond.py (Example 14-4).

Class U is unrelated to A or Root from the diamond module.

What does super().ping() do? Answer: it depends. Read on.

LeafUA subclasses U and A in this order.

If you create an instance of U and try to call ping, you get an error:

    >>> u = U()
    >>> u.ping()
    Traceback (most recent call last):
      ...
    AttributeError: 'super' object has no attribute 'ping'

The 'super' object returned by super() has no attribute 'ping' because the MRO of U has two classes: U and object, and the latter has no attribute named 'ping'.

However, the U.ping method is not completely hopeless. Check this out:

    >>> leaf2 = LeafUA()
    >>> leaf2.ping()
    <instance of LeafUA>.ping() in LeafUA
    <instance of LeafUA>.ping() in U
    <instance of LeafUA>.ping() in A
    <instance of LeafUA>.ping() in Root
    >>> LeafUA.__mro__  # doctest:+NORMALIZE_WHITESPACE
    (<class 'diamond2.LeafUA'>, <class 'diamond2.U'>,
     <class 'diamond.A'>, <class 'diamond.Root'>, <class 'object'>)

The super().ping() call in LeafUA activates U.ping, which cooperates by calling super().ping() too, activating A.ping, and eventually Root.ping.

Note the base classes of LeafUA are (U, A) in that order. If instead the bases were (A, U), then leaf2.ping() would never reach U.ping, because the super().ping() in A.ping would activate Root.ping, and that method does not call super().

In a real program, a class like U could be a mixin class: a class intended to be used together with other classes in multiple inheritance, to provide additional functionality. We’ll study that shortly, in “Mixin Classes”.

To wrap up this discussion of the MRO, Figure 14-2 illustrates part of the complex multiple inheritance graph of the Tkinter GUI toolkit from the Python standard library.

Figure 14-2. Left: UML diagram of the Tkinter Text widget class and superclasses. Right: The long and winding path of Text.__mro__ is drawn with dashed arrows.

To study the picture, start at the Text class at the bottom. The Text class implements a full-featured, multiline editable text widget. It provides rich functionality in itself, but also inherits many methods from other classes. The lefthand side shows a plain UML class diagram. On the right, it’s decorated with arrows showing the MRO, as listed in Example 14-7 with the help of a print_mro convenience function.

>>> def print_mro(cls):
...     print(', '.join(c.__name__ for c in cls.__mro__))
>>> import tkinter
>>> print_mro(tkinter.Text)
Text, Widget, BaseWidget, Misc, Pack, Place, Grid, XView, YView, object

Now let’s talk about mixins.

In the Design Patterns book,8 almost all the code is in C++, but the only example of multiple inheritance is the Adapter pattern. In Python, multiple inheritance is not the norm either, but there are important examples that I will comment on in this section.

class ThreadingHTTPServer(socketserver.ThreadingMixIn, HTTPServer):
    daemon_threads = True

class ThreadingMixIn:
    """Mixin class to handle each request in a new thread."""

    # 8 lines omitted in book listing

    def process_request_thread(self, request, client_address):  
        ... # 6 lines omitted in book listing

    def process_request(self, request, client_address):  
        ... # 8 lines omitted in book listing

    def server_close(self):  
        super().server_close()
        self._threads.join()

Django Generic Views Mixins

Note

You don’t need to know Django to follow this section. I am using a small part of the framework as a practical example of multiple inheritance, and I will try to give all the necessary background, assuming you have some experience with server-side web development in any language or framework.

In Django, a view is a callable object that takes a request argument—an object representing an HTTP request—and returns an object representing an HTTP response. The different responses are what interests us in this discussion. They can be as simple as a redirect response, with no content body, or as complex as a catalog page in an online store, rendered from an HTML template and listing multiple merchandise with buttons for buying, and links to detail pages.

Originally, Django provided a set of functions, called generic views, that implemented some common use cases. For example, many sites need to show search results that include information from numerous items, with the listing spanning multiple pages, and for each item a link to a page with detailed information about it. In Django, a list view and a detail view are designed to work together to solve this problem: a list view renders search results, and a detail view produces a page for each individual item.

However, the original generic views were functions, so they were not extensible. If you needed to do something similar but not exactly like a generic list view, you’d have to start from scratch.

The concept of class-based views was introduced in Django 1.3, along with a set of generic view classes organized as base classes, mixins, and ready-to-use concrete classes. In Django 3.2, the base classes and mixins are in the base module of the django.views.generic package, pictured in Figure 14-3. At the top of the diagram we see two classes that take care of very distinct responsibilities: View and TemplateResponseMixin.

Figure 14-3. UML class diagram for the django.views.generic.base module.

Tip

A great resource to study these classes is the Classy Class-Based Views website, where you can easily navigate through them, see all methods in each class (inherited, overridden, and added methods), view diagrams, browse their documentation, and jump to their source code on GitHub.

View is the base class of all views (it could be an ABC), and it provides core functionality like the dispatch method, which delegates to “handler” methods like get, head, post, etc., implemented by concrete subclasses to handle the different HTTP verbs.¹⁰ The RedirectView class inherits only from View, and you can see that it implements get, head, post, etc.

Concrete subclasses of View are supposed to implement the handler methods, so why aren’t those methods part of the View interface? The reason: subclasses are free to implement just the handlers they want to support. A TemplateView is used only to display content, so it only implements get. If an HTTP POST request is sent to a TemplateView, the inherited View.dispatch method checks that there is no post handler, and produces an HTTP 405 Method Not Allowed response.¹¹

The TemplateResponseMixin provides functionality that is of interest only to views that need to use a template. A RedirectView, for example, has no content body, so it has no need of a template and it does not inherit from this mixin. TemplateResponseMixin provides behaviors to TemplateView and other template-rendering views, such as ListView, DetailView, etc., defined in the django.views.generic subpackages. Figure 14-4 depicts the django.views.generic.list module and part of the base module.

For Django users, the most important class in Figure 14-4 is ListView, which is an aggregate class, with no code at all (its body is just a docstring). When instantiated, a ListView has an object_list instance attribute through which the template can iterate to show the page contents, usually the result of a database query returning multiple objects. All the functionality related to generating this iterable of objects comes from the MultipleObjectMixin. That mixin also provides the complex pagination logic—to display part of the results in one page and links to more pages.

Suppose you want to create a view that will not render a template, but will produce a list of objects in JSON format. That’s why the BaseListView exists. It provides an easy-to-use extension point that brings together View and MultipleObjectMixin functionality, without the overhead of the template machinery.

The Django class-based views API is a better example of multiple inheritance than Tkinter. In particular, it is easy to make sense of its mixin classes: each has a well-defined purpose, and they are all named with the …Mixin suffix.

Figure 14-4. UML class diagram for the django.views.generic.list module. Here the three classes of the base module are collapsed (see Figure 14-3). The ListView class has no methods or attributes: it’s an aggregate class.

Class-based views were not universally embraced by Django users. Many do use them in a limited way, as opaque boxes, but when it’s necessary to create something new, a lot of Django coders continue writing monolithic view functions that take care of all those responsibilities, instead of trying to reuse the base views and mixins.

It does take some time to learn how to leverage class-based views and how to extend them to fulfill specific application needs, but I found that it was worthwhile to study them. They eliminate a lot of boilerplate code, make it easier to reuse solutions, and even improve team communication—for example, by defining standard names to templates, and to the variables passed to template contexts. Class-based views are Django views “on rails.”

Multiple Inheritance in Tkinter

An extreme example of multiple inheritance in Python’s standard library is the Tkinter GUI toolkit. I used part of the Tkinter widget hierarchy to illustrate the MRO in Figure 14-2. Figure 14-5 shows all the widget classes in the tkinter base package (there are more widgets in the tkinter.ttk subpackage).

Figure 14-5. Summary UML diagram for the Tkinter GUI class hierarchy; classes tagged «mixin» are designed to provide concrete methods to other classes via multiple inheritance.

Tkinter is 25 years old as I write this. It is not an example of current best practices. But it shows how multiple inheritance was used when coders did not appreciate its drawbacks. And it will serve as a counterexample when we cover some good practices in the next section.

Consider these classes from Figure 14-5:

➊ Toplevel: The class of a top-level window in a Tkinter application.

➋ Widget: The superclass of every visible object that can be placed on a window.

➌ Button: A plain button widget.

➍ Entry: A single-line editable text field.

➎ Text: A multiline editable text field.

Here are the MROs of those classes, displayed by the print_mro function from Example 14-7:

>>> import tkinter
>>> print_mro(tkinter.Toplevel)
Toplevel, BaseWidget, Misc, Wm, object
>>> print_mro(tkinter.Widget)
Widget, BaseWidget, Misc, Pack, Place, Grid, object
>>> print_mro(tkinter.Button)
Button, Widget, BaseWidget, Misc, Pack, Place, Grid, object
>>> print_mro(tkinter.Entry)
Entry, Widget, BaseWidget, Misc, Pack, Place, Grid, XView, object
>>> print_mro(tkinter.Text)
Text, Widget, BaseWidget, Misc, Pack, Place, Grid, XView, YView, object

Note

By current standards, the class hierarchy of Tkinter is very deep. Few parts of the Python standard library have more than three or four levels of concrete classes, and the same can be said of the Java class library. However, it is interesting to note that the some of the deepest hierarchies in the Java class library are precisely in the packages related to GUI programming: java.awt and javax.swing. Squeak, the modern, free version of Smalltalk, includes the powerful and innovative Morphic GUI toolkit, also with a deep class hierarchy. In my experience, GUI toolkits are where inheritance is most useful.

Note how these classes relate to others:

• Toplevel is the only graphical class that does not inherit from Widget, because it is the top-level window and does not behave like a widget; for example, it cannot be attached to a window or frame. Toplevel inherits from Wm, which provides direct access functions of the host window manager, like setting the window title and configuring its borders.

• Widget inherits directly from BaseWidget and from Pack, Place, and Grid. These last three classes are geometry managers: they are responsible for arranging widgets inside a window or frame. Each encapsulates a different layout strategy and widget placement API.

• Button, like most widgets, descends only from Widget, but indirectly from Misc, which provides dozens of methods to every widget.

• Entry subclasses Widget and XView, which support horizontal scrolling.

• Text subclasses from Widget, XView, and YView for vertical scrolling.

We’ll now discuss some good practices of multiple inheritance and see whether Tkinter goes along with them.

This chapter started with a review of the super() function in the context of single inheritance. We then discussed the problem with subclassing built-in types: their native methods implemented in C do not call overridden methods in subclasses, except in very few special cases. That’s why, when we need a custom list, dict, or str type, it’s easier to subclass UserList, UserDict, or UserString—all defined in the collections module, which actually wrap the corresponding built-in types and delegate operations to them—three examples of favoring composition over inheritance in the standard library. If the desired behavior is very different from what the built-ins offer, it may be easier to subclass the appropriate ABC from collections.abc and write your own implementation.

The rest of the chapter was devoted to the double-edged sword of multiple inheritance. First we saw how the method resolution order, encoded in the __mro__ class attribute, addresses the problem of potential naming conflicts in inherited methods. We also saw how the super() built-in behaves, sometimes unexpectedly, in hierarchies with multiple inheritance. The behavior of super() is designed to support mixin classes, which we then studied through the simple example of the UpperCaseMixin for case-insensitive mappings.

We saw how multiple inhertance and mixin methods are used in Python’s ABCs, as well as in the socketserver threading and forking mixins. More complex uses of multiple inheritance were exemplified by Django’s class-based views and the Tkinter GUI toolkit. Although Tkinter is not an example of modern best practices, it is an example of overly complex class hierarchies we may find in legacy systems.

To close the chapter, I presented seven recommendations to cope with inheritance, and applied some of that advice in a commentary of the Tkinter class hierarchy.

Rejecting inheritance—even single inheritance—is a modern trend. One of the most successful languages created in the 21st century is Go. It doesn’t have a construct called “class,” but you can build types that are structs of encapsulated fields and you can attach methods to those structs. Go allows the definition of interfaces that are checked by the compiler using structural typing, a.k.a. static duck typing—very similar to what we now have with protocol types since Python 3.8. Go has special syntax for building types and interfaces by composition, but it does not support inheritance—not even among interfaces.

During the final review of this book, technical reviewer Jürgen Gmach recommended Hynek Schlawack’s post “Subclassing in Python Redux”—the source of the preceding quote. Schlawack is the author of the popular attrs package, and was a core contributor to the Twisted asynchronous programming framework, a project started by Glyph Lefkowitz in 2002. Over time, the core team realized they had overused subclassing in their design, according to Schlawack. His post is long, and cites other important posts and talks. Highly recommended.

In that same conclusion, Hynek Schlawack wrote: “Don’t forget that more often than not, a function is all you need.” I agree, and that is precisely why Fluent Python covers functions in depth before classes and inheritance. My goal was to show how much you can accomplish with functions leveraging existing classes from the standard library, before creating your own classes.

Subclassing built-ins, the super function, and advanced features like descriptors and metaclasses are all introduced in Guido van Rossum’s paper “Unifying types and classes in Python 2.2”. Nothing really important has changed in these features since then. Python 2.2 was an amazing feat of language evolution, adding several powerful new features in a coherent whole, without breaking backward compatibility. The new features were 100% opt-in. To use them, we just had to explicitly subclass object—directly or indirectly—to create a so-called “new style class.” In Python 3, every class subclasses object.

The Python Cookbook, 3rd ed. by David Beazley and Brian K. Jones (O’Reilly) has several recipes showing the use of super() and mixin classes. You can start from the illuminating section “8.7. Calling a Method on a Parent Class”, and follow the internal references from there.

Raymond Hettinger’s post “Python’s super() considered super!” explains the workings of super and multiple inheritance in Python from a positive perspective. It was written in response to “Python’s Super is nifty, but you can’t use it (Previously: Python’s Super Considered Harmful)” by James Knight. Martijn Pieters’ response to “How to use super() with one argument?” includes a concise and deep explanation of super, including its relationship with descriptors, a concept we’ll only study in Chapter 23. That’s the nature of super. It is simple to use in basic use cases, but is a powerful and complex tool that touches some of Python’s most advanced dynamic features, rarely found in other languages.

Despite the titles of those posts, the problem is not really the super built-in—which in Python 3 is not as ugly as it was in Python 2. The real issue is multiple inheritance, which is inherently complicated and tricky. Michele Simionato goes beyond criticizing and actually offers a solution in his “Setting Multiple Inheritance Straight”: he implements traits, an explict form of mixins that originated in the Self language. Simionato has a long series of blog posts about multiple inheritance in Python, including “The wonders of cooperative inheritance, or using super in Python 3”; “Mixins considered harmful,” part 1 and part 2; and “Things to Know About Python Super,” part 1, part 2, and part 3. The oldest posts use the Python 2 super syntax, but are still relevant.

I read the first edition of Grady Booch et al., Object-Oriented Analysis and Design, 3rd ed., and highly recommend it as a general primer on object-oriented thinking, independent of programming language. It is a rare book that covers multiple inheritance without prejudice.

Now more than ever it’s fashionable to avoid inheritance, so here are two references about how to do that. Brandon Rhodes wrote “The Composition Over Inheritance Principle”, part of his excellent Python Design Patterns guide. Augie Fackler and Nathaniel Manista presented “The End Of Object Inheritance & The Beginning Of A New Modularity” at PyCon 2013. Fackler and Manista talk about organizing systems around interfaces and functions that handle objects implementing those interfaces, avoiding the tight coupling and failure modes of classes and inheritance. That reminds me a lot of the Go way, but they advocate it for Python.