Question

When deriving from a builtin type as well as from some other class, it seems that the builtin type’s constructor doesn’t call the super class constructor. This results in __init__ methods not being called for types that come after the builtin in the MRO.

Example:

class A:
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        print("A().__init__()")

class B(list, A):
    def __init__(self, *args, **kwargs):
        print("B().__init__() start")
        super().__init__(*args, **kwargs)
        print("B().__init__() end")

if __name__ == '__main__':
    b = B()

In this sample, A.__init__ is never called. When B is defined as class B(A, list) instead — switching the inheritance order — it works as intended (i.e. A.__init__ is called).

This very subtle dependence on inheritance order seems rather un-pythonic, is it intended this way? It also means that you must never derive from builtin types in complex class hierarchies, because you can’t know where the builtin ends up in the MRO when someone else derives from your classes (maintenance horror). Am I missing something?

Extra info: Python version 3.1

Answer 1

The correct usage of super() is rather subtle and requires some care if the collaborating methods don’t all have the same signature. The usual pattern for __init__() methods is the following:

class A(object):
    def __init__(self, param_a, **kwargs):
        self.param_a = param_a
        super(A, self).__init__(**kwargs)

class B(A):
    def __init__(self, param_b, **kwargs):
        self.param_b = param_b
        super(B, self).__init__(**kwargs)

class C(A):
    def __init__(self, param_c, **kwargs):
        self.param_c = param_c
        super(C, self).__init__(**kwargs)

class D(B, C):
    def __init__(self, param_d, **kwargs):
        self.param_d = param_d
        super(D, self).__init__(**kwargs)

d = D(param_a=1, param_b=2, param_c=3, param_d=4)

Note that this requires that all methods collaborate, and that all methods need a somewhat compatible signature to ensure it does not matter at which point the method is called.

The constructors of built-in types don’t have constructor signatures that allow participating in such a collaboration. Even if they did call super().__init__() this would be rather useless unless all the constructor signatures were unified. So in the end you are right — they are not suitable for particpation in collaborative constructor calls.

super() can only be used if either all collaborating methods have the same signature (like e.g. __setattr__()) or if you use the above (or a similar) pattern. Using super() isn’t the only pattern to call base class methods, though. If there are no “diamonds” in your multiple inheritance pattern, you can use explicit base class calls, for example B.__init__(self, param_a). Classes with multiple base classes simply call multiple constructors. An even if there are diamonds, you can sometimes use explicit calls, as long as you take care that an __init__() may be called several times without harm.

If you want to use super() for contructors anyway, you indeed shouldn’t use subclasses of built-in types (except for object) in multiple inheirtance hierachies. Some further reading:

• Raymond Hettinger’s Python’s super() considered super!
• James Knight’s Python’s Super is nifty, but you can’t use it