Avoiding the Diamond Problem

Really great video. Once I got through the Multiple Inheritance video about 5 or 6 times to understand the intricacies, this made way more sense and is so much cleaner in terms of inheritance.

Why we call weekly_salary by using the class name SalaryPolicy why we didn’t use super() as we did with id and name and what’s the differencie between the two ways?

I am having issue in my code:

Traceback (most recent call last):
  File "C:/Users/Sada/PycharmProjects1/ProjectRealPython/program.py", line 9, in <module>
    temporary_secretary = employees.SecretaryTemporary(5, 'Robin Williams', 40, 9)
TypeError: __init__() takes 3 positional arguments but 5 were given

And this is my code:

class SecretaryTemporary(Employee, SecretaryRold, HourlyPolicy):
    def __init(self, id, name, hours_worked, hour_rate):
        HourlyPolicy.__init__(self, hours_worked, hour_rate)
        super().__init__(id, name)

Why do I have this kind of exception even though in my code I give the same exact number of arguments? Any help?

@saljon This example uses a mix of the old and the new style of doing inheritance in Python. In the old style, which was common in Python 2.x, you had to indicate the base class by name to initialize it, whereas in Python 3.x, you can also leverage the super() function.

However, things get a little more complicated with multiple inheritance, i.e., when your class extends more than one base class. The super() function will figure out the order of calling the base classes’ initializers, and it’ll pass all its arguments to each. Therefore, if you choose to use super() and need to pass parameters through it, then you also have to make sure that all .__init__() methods in your base classes can accept arbitrary number of parameters. The usual way to do this is with *args and **kwargs:

class Employee:
    def __init__(self, id, name, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.id = id
        self.name = name

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

class SalaryPolicy:
    def __init__(self, weekly_rate, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.weekly_rate = weekly_rate

class Manager(Employee, ManagerRole, SalaryPolicy):
    def __init__(self, id, name, weekly_rate):
        super().__init__(id, name, weekly_rate)

Notice how every class makes a call to super() and declares *args and **kwargs even when it doesn’t accept any parameters in its initializer!

One question, regarding using the payment policies as a standalone class and adding them as super class into employees. Can these be called as mixins? As they don’t inherit from any super class and are pluggable into any type of employee. Am I correct or am I misunderstanding them? Please help.

@iamrsingh That’s about right. Mixins aren’t standalone classes, which only become useful as a part of another class. However, mixins are typically stateless, and they don’t define any member attributes such as weekly_rate.

Hello. I really appreciate the learning content, thank you! I did have one question. Why do we need to pass self when calling .__init__() on a specific base class but not when we call .__init__() with super()?

Thank you, Louis

@lounap Excellent question, Louis!

When you call the .__init__() method on a superclass explicitly, like BaseClass.__init__(self, args), you need to pass self because you access that method using a reference that isn’t bound to any specific object. On the other hand, calling super() returns a concrete instance of your class, so effectively, super() becomes analogous to self in that context.

Here’s a little example to demonstrate that:

>>> class BaseClass:
...     pass
...
>>> class SubClass(BaseClass):
...     def __init__(self):
...         unbound_reference = BaseClass.__init__
...         bound_reference = super().__init__
...
...         unbound_reference(self)
...         bound_reference()
...
...         print(unbound_reference)
...         print(bound_reference)
...
>>> SubClass()
<slot wrapper '__init__' of 'object' objects>
<method-wrapper '__init__' of SubClass object at 0x7f575852be50>
<__main__.SubClass object at 0x7f575852be50>

Notice that the second method reference is bound to the particular object whose identity is 0x7f575852be50, whereas the other reference isn’t.

Thank you! It is starting to sink in. :-)