Multiple Inheritance

Which languages support MRO and which ones don’t? I am especially interested in python vs c# vs java vs php.

Java avoids large bottles of Tylenol by prohibiting multiple inheritance, though does allow “implements” of multiple interfaces. So, the search for a method goes linearly through an explicit single chain of child-parent inheritance and method overrides, or quickly ends at an interface method you’ve explicitly contracted to “implement(s)” in your class (though maybe might be a class you intend to parent … I think Austin mentioned the “abstract” concept back there somewhere). I’m not expert, but I think that’s more or less right … and probably same or similar in C# (I’ve only done a little C#, and long ago).

I needed to watch this video like 5 times and type out the following to understand something about the super() function.

When you called TemporarySecretary(HourlyEmployee,Secretary) at around 3:40 you state the init is being searched for via the following mro path to match the 4 positional arguments passed in:

• TemporarySecretary (no __init__ so move to HourlyEmployee)
• HourlyEmployee (a match with the parameters but because super() is called, it will skip to the next in the mro which is Secretary not the Parent of HourlyEmployee which is Employee)
• Secretary (no __init__ so move to SalaryEmployee)
• SalaryEmployee (__init__ method doesn’t match the 4 positional argument as it has 3). IT CALLS THE SUPER() SO IT WILL MOVE TO EMPLOYEE
• Employee (__init__ method doesn’t match the 4 positional arguments as it has 3 so it would move to object to check).
• Object (Object doesn’t have 4 positional arguments so it fails).

I just want to confirm that super() is called at the SalaryEmployee level like at the HourlyEmployee level and it’s checking the Employee level but it’s init doesn’t match so it fails and checks the parent object.

This is great material by the way and well presented. It’s just taking me multiple goes to wrap my head around the intricacies. Anyone else…just stick with this! It makes sense.

TemporarySecretary() calls –> HourlyEmployee’s init() which matches our TemporarySecretary’s init() with 4 arguments.

HourlyEmployee’s init() calls –> super().__init__() –> which in turn invokes Secretary class’ init() and since our Secretary class’ init() just takes a single argument(and we passed 4) thereby causing a TypeError

I want to try to answer dwalsh’s question slowly and methodically. Hopefully I will not go astray in the process.

When the author called TemporarySecretary(HourlyEmployee,Secretary) at around 3:40 you state the init is being searched for via the following mro path to match the 4 positional arguments passed in …

First let’s repeat the beginning of the class declaration in this particular inheritance configuration:

class TemporarySecretary(HourlyEmployee, Secretary):

Then let’s show the instantiation of that class:

temporary_secretary = employees.TemporarySecretary(5, 'Robin Williams', 40, 9)

And as a final preparation for discussion, let’s outline the MRO for TemporarySecretary in this particular inheritance configuration:

1. <class ‘employees.TemporarySecretary’>
2. <class ‘employees.HourlyEmployee’>
3. <class ‘employees.Secretary’>
4. <class ‘employees.SalaryEmployee’>
5. <class ‘employees.Employee’>
6. <class ‘object’>

When we search for an __init__ method, it is important to realize that Python isn’t going to jump over an __init__ method in the MRO chain that doesn’t match the calling signature. Python looks for the first __init__ it can find. As soon as Python finds an __init__, it compares the signatures between the caller and the method. If those signatures don’t match, an exception will be thrown immediately. No further searching along the MRO chain takes place.

With this in mind, when our initial search occurs for an __init__ method, we first look in TemporarySecretary, and as you noted, because no __init__ was found, we moved along the MRO chain to look in HourlyEmployee. Here we find an __init__ method that also happens to match our calling signature:

def __init__(self, id, name, hours_worked, hour_rate):
        super().__init__(id, name)
        self.hours_worked = hours_worked
        self.hour_rate = hour_rate

It’s important to emphasize that we stop searching for an __init__ method here regardless of whether the signature matches. If the signature had not matched, Python would have immediately thrown an exception and halted execution. But because it does match, we go on to execute that __init__ method with the corresponding arguments.

In the process of executing that method, we immediately come to a new call to super:

super().__init__(id, name)

This call commences a new search for an __init__ method. The signature that we will attempt to match against is also new. We now need an init with only 2 positional arguments (or 3 if you count the implicit self argument). But once again, as soon as any __init__ is found, the search stops. If the signature matches, we proceed to execute. If it does not, an exception is thrown.

It is also important to note here that we will follow the original TemporarySecretary class MRO in our new search for an __init__ method. Successive calls to super follow the original MRO. Because we are currently in HourlyEmployee, the next class in the chain is Secretary. As you noted, Secretary has no __init__. So we then move along to SalaryEmployee, which looks like the following:

class SalaryEmployee(Employee):
    def __init__(self, id, name, weekly_salary):
        super().__init__(id, name)
        self.weekly_salary = weekly_salary

SalaryEmployee has an __init__ but its signature does not match the new caller. The caller supplies id and name, but the SalaryEmployee also requires weekly_salary. In this case, we have too few arguments. Once again, Python stops searching as soon as it finds an __init__ of any signature. Because the signatures do not match, an exception is immediately thrown:

TypeError: __init__() missing 1 required positional argument: ‘weekly_salary’

We never reach Employee or object in our search for an __init__ method.

09:08 Luckily, this is a quick fix. All I’m going to do is define a .calculate_payroll() method in the TemporarySecretary class. And when that is called, I’ll tell it to return the HourlyEmployee’s .calculate_payroll() method.

While calling HourlyEmployee’s init method, why self is used, on the other hand, I do not see self with super()?

super confusing

@agupt039 When you call a method on an object, then Python will implicitly pass the reference to that object as the first argument, which is customarily called self. However, you can also call that same method through the class name and pass the reference to a specific object yourself:

secretary = TemporarySecretary(42, "Anna", 80, 7.25)

# Method bound to the "secretary" instance:
secretary.calculate_payroll()

# Unbound class method:
HourlyEmployee.calculate_payroll(secretary)

The method in the first call is bound to the secretary instance, so Python knows which object to call it upon. The other one is unbound, so you need to provide an object yourself.

The latter way of calling a method can be helpful in the context of inheritance. For example, it lets you delegate a call to another method specified in one of your base classes, like in the video:

def calculate_payroll(self):
    HourlyEmployee.calculate_payroll(self)

That was the only way of doing delegation until the super() function was introduced in Python 2.2. However, the original syntax of the function was a little repetitive because it required both the class and instance parameters to be passed:

class TemporarySecretary(...):
    def calculate_payroll(self):
        super(TemporarySecretary, self).calculate_payroll()

Note that you had to pass the child class instead of the parent one! While you can still use this syntax, the current one lets you write the same without repeating yourself:

class TemporarySecretary(...):
    def calculate_payroll(self):
        super().calculate_payroll()

However, there is a subtle difference between calling super() or super(cls, self) and through a base class name like before. It manifests itself when you’re dealing with multiple inheritance, i.e., when your child class has more than one parent. In such a case, there could potentially be a conflict between identically named methods in your base classes. How would Python know which one to call if you used super() without pinpointing an exact parent class?

To avoid this ambiguity, which is known as the diamond inheritance problem, you can rely on the old syntax. But, it turns out there’s an algorithm called C3 linearization that helps super() sort this out. You can also inspect or even change the default order of your base classes using method resolution order (MRO).

Hi, just a quck question. Is it possible to trace MRO from Jupyter Notebook? Thanks!

@alazejha I don’t see why not. After all, it’s just a class attribute:

>>> class Dad:
...     pass
... 
>>> class Mom:
...     pass
... 
>>> class Child(Mom, Dad):
...     pass
... 
>>> Child.__mro__
(<class '__main__.Child'>, <class '__main__.Mom'>, <class '__main__.Dad'>, <class 'object'>)

On the other hand, if you wanted to introspect the MRO based on an instance, then just do this:

>>> instance = Child()
>>> instance.__class__.__mro__
(<class '__main__.Child'>, <class '__main__.Mom'>, <class '__main__.Dad'>, <class 'object'>)

Why do we need to both call HourlyEmployee.__init__ AND the def __init__ constructor on TemporarySecretary? Doesn’t the init method override it already?

class TemporarySecretary(Secretary, HourlyEmployee):
    def __init__(self, id, name, hours_worked, hour_rate):
        HourlyEmployee.__init__(self, id, name, hours_worked, hour_rate)

@chasemthomas TL;DR It has to do with multiple inheritance. The two parent classes have incompatible initializer signatures, which is why you must intervene by providing one of your own.

When you implement a custom .__init__() method in your subclass, you effectively take control over the object construction process. In most cases, you’ll just call super() to rely on the method resolution order (MRO), which determines your parent class. Alternatively, you can cherry-pick your superclass’ initializers and call them manually, which used to be the old-school way of doing inheritance in Python. Today, it usually indicates that your type hierarchy doesn’t reflect the reality anymore, hence the need for a little bit of hacking. You can avoid such problems by limiting the use of inheritance in favor of composition.

Thanks @Saul for clearly explaining and clearing out that doubt. I had the same question as the one raised by @dwalsh.

Thank @Bartosz Zaczyńsk had the same question for self. Well explained, Much appreciated.

Thanks so much @Saul!