Python self and super in multiple inheritance

Question

In Raymond Hettinger\'s talk \"Super considered super speak\" at PyCon 2015 he explains the advantages of using super in Python in multiple inheritance context. Thi

Answer 1

I'd like to share a few observations on this.

Calling self.get_dough() may be not possible if you are overriding the get_dough() method of the parent class, like here:

class AbdullahStore(DoughFactory):
    def get_dough(self):
        return 'Abdullah`s special ' + super().get_dough()

I think this is a frequent scenario in practice. If we call DoughFactory.get_dough(self) directly then the behaviour is fixed. A class deriving AbdullahStore would have to override the complete method and cannot reuse the 'added value' of AbdullahStore. On the other hand, if we use super.get_dough(self), this has a flavour of a template: in any class derived from AbdullahStore, say

class Kebab(AbdullahStore):
    def order_kebab(self, sauce):
        dough = self.get_dough()
        print('Making kebab with %s and %s sauce' % (dough, sauce))

we can 'instantiate' get_dough() used in AbdullahStore differently, by intercepting it in MRO like this

class OrganicKebab(Kebab, OrganicDoughFactory):pass

Here's what it does:

Kebab().order_kebab('spicy')
Making kebab with Abdullah`s special insecticide treated wheat dough and spicy sauce
OrganicKebab().order_kebab('spicy')
Making kebab with Abdullah`s special pure untreated wheat dough and spicy sauce

Since OrganicDoughFactory has a single parent DoughFactory, I it is guaranteed to be inserted in MRO right before DoughFactory and thus overrides its methods for all the preceding classes in MRO. It took me some time to understand the C3 linearization algorithm used to construct the MRO. The problem is that the two rules

children come before parents
parents order is preserved

from this reference https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ do not yet define the ordering unambiguously. In the class hierarchy

D->C->B->A
 \      /
   --E--

(class A; class B(A); class C(B); class E(A); class D(C,E)) where E will be inserted in MRO? Is it DCBEA or DCEBA? Perhaps before one can confidently answer questions like this, it is not such a good idea to start inserting super everywhere. I am still not completely sure, but I think C3 linearization, which is unambiguous and will choose the ordering DCBEA in this example, does allow us to do the interception trick the way we did it, unambiguously.

Now, I suppose you can predict the result of

class KebabNPizza(Kebab, OrganicPizza): pass
KebabNPizza().order_kebab('hot')

which is an improved kebab:

Making kebab with Abdullah`s special pure untreated wheat dough and hot sauce

But it has probably taken you some time to calculate.

When I first looked at the super docs https://docs.python.org/3.5/library/functions.html?highlight=super#super a weak ago, coming from C++ background, it was like "wow, ok here are the rules, but how this can ever work and not stub you in the back?". Now I understand more about it, but still reluctant from inserting super everywhere. I think most of the codebase I have seen is doing it just because super() is more convenient to type than the base class name. And this is even not speaking about the extreme use of super() in chaining the __init__ functions. What I observe in practice is that everybody write constructors with the signature that is convenient for the class (and not the universal one) and use super() to call what they think is their base class constructor.