many people will tell you super() is a nifty tool in python; it allows you to call a method in super class without specifying super class name:

##  example 0

class A:
    def __init__(self):
        print('A')

class B(A):
    def __init__(self):
        super().__init__()  # instead of `A.__init__(self)`
        print('B')

B()

output:

A
B

this allows you to change super class name while using the same code at call site;

however, if you think super() means to return the super class, you are horribly wrong; the problem manifests itself when you start programming with multiple inheritance;

a simple counter example is to extend the above example like this:

##  example 1

class A:
    def __init__(self):
        print('A')

class B(A):
    def __init__(self):
        super().__init__()
        print('B')

class C(A):
    def __init__(self):
        print('C')

class D(B, C): pass

D()

output:

C
B

now you can see super() in B doesnt direct to A but C;

demystify super

in python, each class has a method resolution order; it defines the order of method search; for example, in example 1, the mro of class D is DBCA; the class next to B is C; that is why super() in B refers to C (not A);

in fact, the signature of super() is super(class, mro_class), whose exact semantic is:

  • return a proxy object that delegates method calls to the next class of class in the mro of mro_class;

for example, if D extends C extends B extends A, then D has mro DCBA, so super(C, D) returns B; note that, for sake of brevity, in this article we do not distinguish the returned proxy object and its proxied object; you should know super(C, D) is a proxy of B, not B itself;

call signatures

the classic form of super() is super(class, mro_class); we recommend you to use this form whenever possible; in addition, super() also has several other call signatures:

  1. super(class, mro_obj):

    super() allows to use a non-type object mro_obj as the second parameter; in this form, the mro is inferred from the class of mro_obj; plus, proxied method calls are bound to mro_obj;

  2. super(class):

    super() allows to omit the second parameter; in this form, the returned proxy object is an unbound super; this is very tricky and it is recommended not to use this form at all;

  3. super():

    super() allows to omit both parameters when used inside class definition; in this form, the compiler fills in the missing parameters:

    class C(B):
    def method(self, arg):
        super().method(arg)    # This does the same thing as:
                               # super(C, self).method(arg)

solution

now back to our problematic example 1; the problem happens because:

  • when we call super().__init__() in B.__init__, we mean to call A.__init__;

  • however, in our multiple inheritance heterarchy, super(), which is equivalent to super(B, self), works like (a bound version of) super(B, D) (because self is an instance of D), and resolves to C (because D has mro DBCA);

to fix this, we need to pass super() the correct mro (B, not D):

##  example 2

class A:
    def __init__(self):
        print('A')

class B(A):
    def __init__(self):
        super(B, B).__init__(self)  # super(B, B) not super(B, D)
        print('B')

class C(A):
    def __init__(self):
        print('C')

class D(B, C): pass

D()

output:

A
B

conclusion

  • if you use super() to indirectly name super class, you should always use its two-argument form super(class, mro_class) with both classes set to the current class (like super(X, X)); this limits method resolution to the class itself and its super classes (a property which i call forward secrecy);

    within methods, you can also use super(__class__, __class__) to avoid explicit class names:

    class B(A):
    def __init__(self):
        super(__class__, __class__).__init__(self)
        print('B')

    __class__ is an implicit closure reference created by the compiler if any methods in a class body refer to either __class__ or super.

  • if you use super(), in its zero-argument form, to support cooperative multiple inheritance, i suggest you give up this idea unless you really really need it and your classes are only to be used by yourself;

    the reason is, as you have seen in example 0 and 1, you do not know which class your super() resolves to when you are writing class B; users who extend class B need to check super() calls are wired correctly across the whole class heterarchy, which can be huge burden and inflexibility;

  • unfortunately, python uses super() by default, which means if you omit a method override, a default implemention based on super() is assumed:

    class B(A): pass

    works like:

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

    this effectively passes the method call to the next candidate in the object mro, producing a no-op effect; this is nifty with the assumed cooperative multiple inheritance paradiam, but is at a discrepancy from the idea that each class only cares about itself and its own superclasses;

combining all these points, i came to the conclusion that super()-based cooperative multiple inheritance in python is an anti-pattern; the idea of cooperative multiple inheritance (broad sight) and the idea of forward secrecy (narrowed sight) cannot be easily reconciled; furthermore, super() in python is a misnomer; if you want to use it correctly, remember this all the time: super() means next, not parent;