Multiple Inheritance in Python

Superbly motivated, organized, and paced. Most appreciated

Thank you,especially for the Mixins example.

Yea, I have read the documentation multiple times, but the way this was presented made it extremely digestible and clear - very well put together. Now to watch it 5 more times.

Great tutorial! Thanks!

Best explanation I have seen. Thank you!

I came to this tutorial to understand to concept of Mixins. I really happy I got everything in less than 30 minutes. Really appreciate such explanation simplicity!

I liked the explanation of the “why” in creating Mix-ins and the potential pitfalls of multiple-inheritance. I love the explanations simplicity and your measured vocal speed. Keep up the Good Work!!

Fantastic tutorial! I really enjoyed how concise and to the point all three videos were, with solid examples. The introduction of the mixin pattern however made all the difference in the end. I’ll be decoupling some code at work pretty soon with this :) Thanks!

I’m lost!

@richardoaparicio92 What are you struggling with?

This is great, so thank you! My purpose was to understand how OOP works in Python, so that I am capable of designing good code when I need to.

My favorite thing was the mro method and using mixins to prevent confusion. Definitely my plan, if possible since confusing code creates bugs that are time-consuming to fix.

Really useful - a few pennies dropped right here. The only thing I didn’t get was the final cube = SACube(3) I suspect this was an error - I couldn’t find any ref to class SACube anywhere - but maybe I missed it - overall - a great concise tutorial

Hi graham17,

Good catch. That’s an artifact from an earlier version of the code. We’ll fix it shortly. Thanks for letting us know. …ct

In case of single inheritence why use super() method when we could call the method using class name directly ??. I mean what is the advantage ?

class Rectangle: def init(self,length,width): self.length = length self.width = width

def area(self):
    return (self.length * self.width)

def permiter(self):
    return (2 * self.length + 2 * self.width)

class Square(Rectangle):

def __init__(self,length):
    Rectangle.__init__(self,length,length) >>>>>>>>>>>>>>>>>>>>calling Rectangle,method() directly instead of super
    #super().__init__(length,length)

Crystal clear explanation of concepts such as MRO and Mixins! Thanks a lot.

You pointed out with Cube that you could access Rectangle.area() either by self.area() or super().area. What’s best practice? I would imagine best practice is to use self.parent_method unless there is a name clash, as with __init__ in subsequent examples.

Hi Nathan,

Generally, you use self.method() unless there is a reason to do otherwise. If I’m having to get at the parent, then super(), or if there is some situation where clarity is needed that I’m calling a parent method.

Encountered this code in “Creating custom Model Managers in Django” in Django by Example Book.

GIVEN the following code

class PublishedManager(models.Manager):
    def get_queryset(self):
        return (
            super(PublishedManager, self) 
                .get_queryset()
                .filter(status='published')
                )

class Post(models.Model):
    objects = models.Manager()
    published_objects = PublishedManager()
    publish = models.DateTimeField(default=timezone.now)

AND GIVEN objects is the default Model manager for Post,

THEN the code super(PublishedManager, self) is equivalent to calling the default manager Object - objects.get_queryset() from within an instance of the PublishedManager class right ?

Hi nj8456,

Yes, you’re right. PublishedManager is overriding models.Manager.get_queryset(), so within that override, if you called self.get_queryset() you would get the overridden instance – a recursive call. The use of super() here gets you at the parent’s method.

This is a common pattern in Django models. You do something similar if you want to override a Model’s save() method – call the parent, to do what it would normally do, then run your specialized code.

In the case of PublishedManager.get_queryset(), you want to do a query just like the parent, but this time also apply a filter. The parent is called, then the filter is applied, then the filtered result is returned.

The brackets notation is a short form for doing:

qs = super(Published Manager, self).get_queryset()
return qs.filter(status='published')

Because get_queryset() returns a QuerySet, the:

fn()
.other_fn()
.more_fn()

pattern, chains the results of each of them together, calling the next function on whatever was returned by the previous.

Since class A or X here are the ones last in the forward and backward classes, we get done with the chain. But does it mean the class object init is also called here when last on the chain?

class A:
    def __init__(self):
        print('A')
        super().__init__()

Last on the chain or if even if this was just a single class calling it’s super() does mean calling object right as it is the parent?

Hi Omkar,

Yeah, that one’s a bit tricky. On its own A wouldn’t need the super().init() because it’s super is just the base Object class.

Where it becomes important is through the chaining. In the case of the Backward class, A’s super().init() does nothing. In the case of the Forward class, it is why X’s constructor gets called.

super() calls the next class in the MRO.

The chain works like this:

Backward -> X -> B -> A

So A’s call to super().init() does nothing. By contrast though:

Forward -> B -> A -> X

In this case, without A’s super().init(), X’s init method would not get called.

If you are writing classes that are likely to be mixed in or used with inheritance, it is always good practice to call “super().init()” in case other programmers using your class change the order of inheritance.

Thanks for the crystal clear explanation :) Enjoying being a part of this community!

I didn’t quite understand this part of the mixin:

class Cube(Square, SurfaceAreaMixin):
    ...
        self.surfaces = [Square, Square, Square, Square, Square, Square]

class RightPyramid(Square, Triangle, SurfaceAreaMixin):
    ...
        self.surfaces = [Square, Triangle, Triangle, Triangle, Triangle]

Why are they with these values? I’m from Brazil and as this video is still without subtitles it was a little difficult for me to understand. Thanks.

Hi James,

The idea here was to highlight what a Mixin is used for: code that is common across some classes without necessarily having deep knowledge about the class.

The SurvaceAreaMixin.surface_area() method calculates the surface area of a 3D shape by looking for an attribute named “surfaces” and calling the area() method for each of the surfaces, adding them together.

A Cube has six sides, each of which is a square. By setting Cube.surfaces to be six Squares, the mixin’s surface_area() method will correctly calculate the surface area of a Cube.

The RightPyramid is comprised of a square base and four triangular sides. It represents this by setting its “surfaces” attribute to [Square, Triangle, Triangle, Triangle, Triangle].

The mixin knows on an abstract level how to calculate surface area (by calling the area() method on each shape in the “surfaces” attribute), but doesn’t need to know what the surfaces are for the object inheriting the mixin.

The specifics of the 3D shape are described in the implementation of the class (Cube or RightPyramid), but the algorithm for calculating the surface area can be separated out from this into a common mixin class.

Without the mixin, you would need to write separate surface_area() methods for the Cube and RightPyramid. Having it in the mixin means writing and testing it in only one place.

Very clear and well-explained!

Excellent material! I have a small quibble and some hopefully useful observations. Please correct me if I go astray. At around the 7:18 mark, it is noted that the Square class constructor receives base, slant_height, height, and length as arguments. But slant_height is not actually included among those arguments. It was captured as a positional parameter in the constructor for RightPyramid, along with base. The reason base itself gets passed up the chain is because we specifically re-submit base in the super().__init__(base=base, **kwargs) method call. We don’t re-submit slant_height because it isn’t used by any superclasses.

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)

In fact, if we had included slant_height, an exception would later result when the super().__init__(**kwargs) call to object ultimately occurred:

TypeError: object.init() takes no parameters

Using super().__init__(**kwargs) in this way to chain across multiple inheritance hierarchies (by following the MRO) means that we cannot have any extraneous or unused keyword arguments. They have to be captured by parameters with the same name in a constructor somewhere in the chain. That’s the only way they get consumed and removed from the kwargs dictionary.

Another thing: I was a bit troubled at first by the assignment to the kwargs dictionary in the constructor for RightPyramid. I couldn’t figure out why we would pass along height and length as arguments with these assignment statements but then pass along base as an argument in the super().__init__ call. Well it seems that these approaches are equivalent. We could have also done either of the following just as well:

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
        kwargs["base"] = base
        super().__init__(**kwargs)

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

Again, please let me know if I am missing something. Thanks!

Hi Saul,

Thanks for your comments.

At around the 7:18 mark, it is noted that the Square class constructor receives base, slant_height, height, and length as arguments. But slant_height is not actually included among those arguments.

I believe what I was attempting convey was that slant_height gets passed in but as the height argument. You are correct that slant_height is not kept as a named argument.

Your are also correct that you have to be careful with these things and what gets consumed. You only have to make sure they all get used if there is a class somewhere with an empty init(), if your constructors always have the *args, **kwargs arguments you should be ok (he writes nervously without testing :) ). That being said, this is why I tend to prefer to use inheritance for Mixins only. These kinds of subtleties can definitely cause you weird problems both at compile and runtime.

I was a bit troubled at first by the assignment to the kwargs dictionary … Well it seems that these approaches are equivalent.

Yep, you’re right. It has been too long since I wrote that code, I don’t remember why I did it that way. I suspect it had something to do with how it evolved out of earlier versions. Either approach works.

Happy coding!

Great tutorial on inheritance!

Great tutorial, and very clearly explained.

There is one thing I’m not completely convinced and that is the Mixin example. The method surface_area() in the SurfaceAreaMixin class uses the self.surfaces which you defined in the sub-classes. That sounds a little weird to me. How would I know from the Mixin class which instance variables I must define so the method would not crash with an AttributeError. Is that best practice? Should that be learned from the documentation or by code inspection? Shouldn’t the self.surfaces be at least declared in an __init__() method of the Mixin class?

Thanks, Rik

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