Multiple Inheritance in Python

Hi @rikhuygen,

Yep, this is one of the challenges of trying to teach mixins and object oriented lessons. The really good uses of this kind of tech tend to require more background information.

The whole “using shapes” thing to explain OO inheritance is tried and true but has its limitations. Even if I was going to write a graphic interface that used shapes, I likely wouldn’t go full OO, or if I did, the base class would be much lighter than is used in typical explanations.

The best place for things like Mixins are where you have a lot of independence and are trying to add a feature that isn’t quite specific.

For example, I recently wrote something in Django that required a special kind of identifier. The identifier was a little more complicated than just a field and needed some methods. All of this was put inside of a mixin so that any Django object that needed this kind of identifier would just mix that in. The problem with teaching with this kind of example is then you have to explain what Django is, and how it models objects and how that relates to fields and a whole bunch of other stuff.

To your specific question, the amount of code saved by using this mixin probably doesn’t warrant the hiding of the implementation that happens the way it was done. In the real world I probably wouldn’t have coded it that way, but then I wouldn’t have had a mixin example.

Fair enough, thanks for your answer. (sorry for my late reply)

Hi, Christoph, i’ve enjoyed the tutorial. Could you please answer to my following 2 questions (kind of similar to @Saul, but not entirely i guess):

–1. Is a bad practice to create instance variables(instead of passing it through kwargs) in the init of the Child class, if they are consumed only in the Parent classes, like in the first part of the following example:

class RightPyramid( Triangle,Square):
    def __init__(self, base, slant_height):#no kwargs
        self.base = base
        self.slant_height = slant_height
        self.width = self.base #added width in self
        self.length = self.width #added length in self
        super().__init__(base=self.base,height = self.slant_height) #no kwargs


class RightPyramid( Triangle,Square):
    def __init__(self, base, slant_height,**kwargs): #added kwargs
        self.base = base
        self.slant_height = slant_height
        kwargs['length'] = self.base #added k/v for length
        super().__init__(base=self.base,height = self.slant_height,**kwargs) #added kwargs

–2. What would be the difference between passing the variable in kwargs or passing it separately through the keyword argument?

class RightPyramid( Triangle,Square):
    def __init__(self, base, slant_height,**kwargs):
        self.base = base
        self.slant_height = slant_height
        #kwargs['length'] = self.base # pass by kwargs
        super().__init__(base=self.base,height = self.slant_height,length=self.base,**kwargs) # pass by extra keyword

Sorry, just a later note, i guess having mixings is a nice feature, but one disadvantage(please correct me if wrong) is that it is polluting the instance with the unrelated instance variables of the RightPyramid class for example:

class RightPyramid(Square, Triangle, SurfaceAreaMixin):
    def __init__(self, base, slant_height):
        self.base = base
        self.slant_height = slant_height
        self.height = slant_height #not needed directly by the class
        self.length = base #not needed directly by the class
        self.width = base #not needed directly by the class

        self.surfaces = [Square, Triangle, Triangle, Triangle, Triangle]

Hi Alex,

Use of **kwargs is the more general case, and I might do it if I’m not trying to expose just what the parent is doing. It is kind of a catch-all. If you’re building structures where you’re inheriting directly, there is nothing wrong with using named arguments instead.

One advantage of **kwargs is pass-through to the next level. The best example I can think of is on database objects in Django: they have a save() method that takes a number of parameters. You can override a save() in a child class and only use the arguments that you need, but if some other coder comes along and needs the arguments you didn’t declare, they’re stuck. So best practice is to use **kwargs for those things you’re not using and pass them all to the parent call.

It really just comes down to a design decision though.

As for your question about polluted classes, yeah, in this case that is an unfortunate side-effect. Shapes are a good analogy for teaching inheritance concepts, but are just an analogy. The best examples of mixins usually require deeper understanding of other systems than is helpful when teaching.

My most commonly used mixin is again in the Django space. I like to have date/time stamps on all database tables that track when a row was created and last updated. It can be useful when debugging production problems. As such, the mixin has these fields in it and just gets added to any data class I create. As these fields and any associated methods are independent of the classes mixing them in, there is no pollution problem. Teaching with this example is problematic though, because you can’t run the code unless you’ve got all the Django stuff setup, and so you’re left with having to use mediocre analogies.

With a lot of this stuff it comes down to practice. Even with practice there are plenty of times where I got bit by a design decision I’ve made and then have to come back in and change it to something else later. Welcome to the fun of coding :)

Hi Chris,

I enjoy your videos very much. At around 8:00, when you show all classes and their __init__ methods, RightPyramid is calling Square’s __init__ with a base keyword, which it doesn’t have. Shouldn’t the last line read:

super().__init__(length=base, **kwargs) ?

Thanks

Hi Andras,

Multiple inheritance is tricky.

class RightPyramid(Square, Triangle):
    def __init__(self, base, slant_height, **kwargs):
        self.base = base
        self.slant_height = slant_height
        kwargs["height"] = slant_height
        kwargs["length"] = base
        super().__init__(base=base, **kwargs)

The RightPyramid is inheriting from both Square and Triangle. In this code I’m using base, height, and length in super().__init(). With the base being specified explicitly, and the height and length in kwargs.

You’re right that the Square has no base, but because the arguments are named, and because Square accepts **kwargs: base gets passed in but ignored.

The length value that Square accepts is set in the kwargs dictionary inside RightPyramid, and in fact is a copy of base.

If Square and Triangle did not have **kwargs in their constructors, this code would not work. Since they do have **kwargs, you can pass anything you want in as a named argument, but their respective __init__ code only uses the named arguments they’re interested in. Everything else gets ignored.

Hope this helped.

Hi Chris,

Thanks for the answer. I think most of my confusion came from how **kwargs are handled in general; it was not directly related to multiple inheritance. My previous proposal would have resulted in TypeError: Square.__init__() got multiple values for argument 'length' if I ran it, which I did not (shame on me). Now that I understand **kwargs better, let me ask one more minor thing: when you write the RightPyramid constructor, you know the direct parent is Square, so you could pass lenght=base directly and pass on everything else in kwargs that other parents (further up the chain) will need, like this:

class RightPyramid(Square, Triangle):
    def __init__(self, base, slant_height, **kwargs):
        self.base = base
        self.slant_height = slant_height
        kwargs["height"] = slant_height
        kwargs["base"] = base  # note "base" key!!!

        super().__init__(length=base, **kwargs)  # keyword length=base
        #super().__init__(base, **kwargs)  # positional arg would work too

Was there any specific reason why you “hid” length in kwargs and passed base explicitly? With your approach kwargs inside Square.__init__ becomes a different dict than the one you passed in. This is not a problem, I understand it now. This is the magic Python gives us automatically with kwargs functionality (select what’s needed, ignore everything else). Just asking if there was any trick or design pattern you followed that I should keep in mind too when writing similar code.

regards, Andras

Hi Andras,

Glad you figured it out. Given the course is four years old, I’m not sure I can say exactly what was going through my head when I coded it.

I could argue the more generic use of keyword values is slightly safer in the case where you end up changing the inheritance order, but I’m not sure how important that is. If I was doing a code review, I’m not sure I would be too worried about this case.

The secret reality of all this stuff is that I very seldom use multiple inheritance. It is far more common in other languages (and sometimes far more necessary). Although it is a core computer science concept, and a useful tool in your toolbag, it is only one of a choice of approaches. When I do use multiple inheritance, it tends to be for mixins, which by definition have argument-less constructors, so this particular case we’re discussing doesn’t come up.

If you enjoy the OO aspect of Python and want to understand a bit more, one of the more recent courses does an in depth dive. It has three parts, covering:

• Class concepts, including attributes and methods (realpython.com/courses/python-class-object/)
• Inheritance and class internals (realpython.com/courses/python-class-inheritance/)
• Design guidance (realpython.com/courses/solid-principles-python/)

There is some overlap with this course, but far more depth. The third course talks about some of the rules of object-oriented design and touches on some of the whens/whys of usage.

Happy coding!

Thank you very much, Chris! I just finished that three-part course few days ago. I enjoyed it very much, especially the last part on design. I have many years C++ experience and I feel like I am still looking for the same design principles in Python that I used to work with in C++. It would be nice if you could put together some courses comparing Python vs C++ or Java, and explain what’s the pythonic approach to the most common problems in OOP that are usually tackled with design patterns in C++/Java (singleton, visitor pattern, etc.)

Keep up the good work!

cheers, Andras