Python super method and calling alternatives

Question

I see everywhere examples that super-class methods should be called by:

super(SuperClass, instance).method(args)

Is there any disadvantage

Answer 1

There's no penalty as-is, though your example is somewhat misguided. In the first example, it should be

super(SubClass, instance).method(args)  # Sub, not SuperClass

and that leads me to quote the Python docs:

There are two typical use cases for super. In a class hierarchy with single inheritance, super can be used to refer to parent classes without naming them explicitly, thus making the code more maintainable. This use closely parallels the use of super in other programming languages.

The second use case is to support cooperative multiple inheritance in a dynamic execution environment. This use case is unique to Python and is not found in statically compiled languages or languages that only support single inheritance. This makes it possible to implement “diamond diagrams” where multiple base classes implement the same method. Good design dictates that this method have the same calling signature in every case (because the order of calls is determined at runtime, because that order adapts to changes in the class hierarchy, and because that order can include sibling classes that are unknown prior to runtime).

Basically, by using the first method you don't have to hard-code your parent class in there for single-class hierarchies, and you simply can't really do what you want (efficiently/effectively) using the second method when using multiple inheritance.

Answer 2

Consider the following situation:

class A(object):
    def __init__(self):
        print('Running A.__init__')
        super(A,self).__init__()
class B(A):
    def __init__(self):
        print('Running B.__init__')        
        # super(B,self).__init__()
        A.__init__(self) 

class C(A):
    def __init__(self):
        print('Running C.__init__')
        super(C,self).__init__()
class D(B,C):
    def __init__(self):
        print('Running D.__init__')
        super(D,self).__init__()

foo=D()

So the classes form a so-called inheritance diamond:

    A
   / \
  B   C
   \ /
    D

Running the code yields

Running D.__init__
Running B.__init__
Running A.__init__

That's bad because C's __init__ is skipped. The reason for that is because B's __init__ calls A's __init__ directly.

The purpose of super is to resolve inheritance diamonds. If you un-comment

# super(B,self).__init__()

and comment-out

A.__init__(self) 

the code yields the more desireable result:

Running D.__init__
Running B.__init__
Running C.__init__
Running A.__init__

Now all the __init__ methods get called. Notice that at the time you define B.__init__ you might think that super(B,self).__init__() is the same as calling A.__init__(self), but you'd be wrong. In the above situation, super(B,self).__init__() actually calls C.__init__(self).

Holy smokes, B knows nothing about C, and yet super(B,self) knows to call C's __init__? The reason is because self.__class__.mro() contains C. In other words, self (or in the above, foo) knows about C.

So be careful -- the two are not fungible. They can yield vastly different results.

Using super has pitfalls. It takes a considerable level of coordination between all the classes in the inheritance diagram. (They must, for example, either have the same call signature for __init__, since any particular __init__ would not know which other __init__ super might call next, or else use **kwargs.) Furthermore, you must be consistent about using super everywhere. Skip it once (as in the above example) and you defeat the entire purpose of super. See the link for more pitfalls.

If you have full control over your class hierarchy, or you avoid inheritance diamonds, then there is no need for super.