{"id":50232,"date":"2021-11-18T18:09:43","date_gmt":"2021-11-18T12:39:43","guid":{"rendered":"https:\/\/www.mygreatlearning.com\/blog\/inheritance-in-python\/"},"modified":"2026-01-23T15:53:04","modified_gmt":"2026-01-23T10:23:04","slug":"inheritance-in-python","status":"publish","type":"post","link":"https:\/\/www.mygreatlearning.com\/blog\/inheritance-in-python\/","title":{"rendered":"Inheritance in Python"},"content":{"rendered":"\n

Inheritance is a way to form relationships between classes. You have a \"parent\" class (also called a base class or superclass) and a \"child\" class (a derived class or subclass). The child class gets all the methods and properties of the parent class. That's it. It\u2019s a mechanism for code reuse. Don't repeat yourself (DRY) is a core programming principle, and inheritance is one way to achieve it.<\/p>\n\n\n\n

\n
\n
\n
<\/div>\n Academy Pro<\/span>\n <\/div>\n

\n Python Programming Course<\/a>\n <\/p>\n

In this course, you will learn the fundamentals of Python: from basic syntax to mastering data structures, loops, and functions. You will also explore OOP concepts and objects to build robust programs.<\/p>\n

\n
\n
<\/div>\n 11.5 Hrs<\/span>\n <\/div>\n
\n
<\/div>\n 51 Coding Exercises<\/span>\n <\/div>\n <\/div>\n \n Start Free Trial\n
<\/div>\n <\/a>\n <\/div>\n <\/div>\n\n\n\n

Why use it?<\/h2>\n\n\n\n

Imagine you're coding a game. You have Enemy objects. Goblins, Orcs, and Dragons are all enemies. They all have health, can take damage, and can attack. Instead of writing that code three times, you create a base Enemy class with that shared logic. Then, your Goblin, Orc, and Dragon classes can inherit from Enemy. They get all the Enemy functionality for free, and you can add specific things to each, like a Dragon's breathe_fire()<\/code> method.<\/p>\n\n\n\n

Here's the basic syntax. No magic here.<\/p>\n\n\n

\n# Parent class\nclass Enemy:\n    def __init__(self, name, health):\n        self.name = name\n        self.health = health\n\n    def take_damage(self, amount):\n        self.health -= amount\n        print(f"{self.name} takes {amount} damage, {self.health} HP left.")\n\n# Child class\nclass Goblin(Enemy):\n    # This class is empty, but it already has everything from Enemy\n    pass\n\n# Let's use it\ngrog = Goblin("Grog the Goblin", 50)\ngrog.take_damage(10)  # This method comes from the Enemy class\n# Output: Grog the Goblin takes 10 damage, 40 HP left.\n<\/pre><\/div>\n\n\n
Types of Inheritance<\/h2>\n\n\n\n
There are a few ways to structure this parent-child relationship.<\/p>\n\n\n\n
1. Single Inheritance<\/h3>\n\n\n\n
This is what you just saw. One child class inherits from one parent class. It's the simplest and most common form of inheritance. Square<\/code> inherits from Rectangle<\/code>, Rectangle<\/code> inherits from Shape<\/code>. Clean and linear.<\/p>\n\n\n\n
2. Multilevel Inheritance<\/h3>\n\n\n\n
This is just a chain of single inheritance. A is the grandparent, B is the parent, and C is the child. C inherits from B, and B inherits from A. This means C gets all the methods and properties from both B and A.<\/p>\n\n\n
\nclass Organism:\n    def breathe(self):\n        print("Inhale, exhale.")\n\nclass Animal(Organism):\n    def move(self):\n        print("Moving around.")\n\nclass Dog(Animal):\n    def bark(self):\n        print("Woof!")\n\nmy_dog = Dog()\nmy_dog.bark()   # From Dog\nmy_dog.move()   # From Animal\nmy_dog.breathe() # From Organism\n<\/pre><\/div>\n\n\n
This can get messy if the chain is too long. Deep inheritance hierarchies are often a sign of bad design.<\/p>\n\n\n\n
3. Multiple Inheritance<\/h3>\n\n\n\n
This is where a single child class inherits from multiple parent classes at the same time. This is where Python gets powerful, and also dangerous.<\/p>\n\n\n
\nclass Flyer:\n    def fly(self):\n        print("I am flying.")\n\nclass Swimmer:\n    def swim(self):\n        print("I am swimming.")\n\nclass Duck(Flyer, Swimmer):\n    def quack(self):\n        print("Quack!")\n\ndonald = Duck()\ndonald.fly()\ndonald.swim()\ndonald.quack()\n<\/pre><\/div>\n\n\n
The Duck<\/code> class can both fly and swim because it inherits from both Flyer<\/code> and Swimmer<\/code>. This sounds great, but it introduces a major problem: What if both parent classes have a method with the same name? This is known as the \"Diamond Problem<\/a>,\" and it leads us to the next critical topic.<\/p>\n\n\n\n
Method Resolution Order (MRO)<\/h2>\n\n\n\n
When you call a method on an object from a class that uses multiple inheritance, how does Python know which parent's method to use? It follows a specific order called the Method Resolution Order (MRO<\/a>).<\/p>\n\n\n\n
The MRO defines the sequence of classes to search when looking for a method. Python uses an algorithm called C3 linearization to figure this out. The key rules are that a child class is checked before its parents, and if there are multiple parents, they are checked in the order you list them in the class definition.<\/p>\n\n\n\n
You can see the MRO for any class by using the .mro()<\/code> method or the __mro__<\/code> attribute.<\/p>\n\n\n
\nclass A: pass\nclass B(A): pass\nclass C(A): pass\nclass D(B, C): pass\n\nprint(D.mro())\n<\/pre><\/div>\n\n\n
Output:<\/p>\n\n\n
\n[&lt;class '__main__.D'>, &lt;class '__main__.B'>, &lt;class '__main__.C'>, &lt;class '__main__.A'>, &lt;class 'object'>]\n<\/pre><\/div>\n\n\n
When you call a method on a D<\/code> object, Python will look for it in this order: D<\/code>, then B<\/code>, then C<\/code>, then A<\/code>, and finally the base object class that everything in Python inherits from. The first place it finds the method, it stops and uses that one. This predictability is crucial for managing complex inheritance structures.<\/p>\n\n\n\n
The super() Function: Your Best Friend in Inheritance<\/h2>\n\n\n\n
When you have a child class, you often want to extend the parent's method, not completely replace it. For example, in the child's __init__<\/code>, you first need to run the parent's __init__<\/code> to set up all the inherited attributes.<\/p>\n\n\n\n
You do this with super()<\/code>. The super()<\/code> function gives you a way to call the parent class's methods. More accurately, it allows you to call the next method in the MRO chain.<\/p>\n\n\n\n
Let's fix our Enemy<\/code> example to add a Goblin-specific attribute.<\/p>\n\n\n
\nclass Enemy:\n    def __init__(self, name, health):\n        self.name = name\n        self.health = health\n\nclass Goblin(Enemy):\n    def __init__(self, name, health, has_club):\n        # Call the parent's __init__ to handle name and health\n        super().__init__(name, health)\n        # Now add the child-specific attribute\n        self.has_club = has_club\n\ngrog = Goblin("Grog", 50, True)\nprint(grog.name)       # Output: Grog\nprint(grog.has_club)  # Output: True\n<\/pre><\/div>\n\n\n
Without super().__init__(name, health)<\/code>, the grog<\/code> object would never get its .name<\/code> or .health<\/code> attributes because the Enemy.__init__<\/code> would never be called. You replaced it, but you didn't extend it. super()<\/code> solves this.<\/p>\n\n\n\n
super()<\/code> is essential for making multiple inheritance work properly. If you call parent methods directly by name (e.g., B.__init__(self, ...)<\/code>), you can end up calling the same method from a common ancestor multiple times, which leads to bugs. super()<\/code> respects the MRO and ensures each method in the inheritance chain is called only once.<\/p>\n\n\n\n
Is Inheritance Always the Answer? (No.)<\/h2>\n\n\n\n
Inheritance is a powerful tool, but it's often overused by beginners. It creates a tight coupling between your classes. A change in the parent can break all the children.<\/p>\n\n\n\n
The main alternative is Composition<\/a>. Instead of a class being something (inheritance), it has something (composition).<\/p>\n\n\n\n
Let's say you have a Car<\/code> class. You could have it inherit from a Vehicle<\/code> class. But what about its engine? A Car<\/code> isn't an Engine<\/code>, a Car<\/code> has an Engine<\/code>. So you would create a separate Engine<\/code> class and give your Car<\/code> an engine<\/code> attribute that is an instance of the Engine<\/code> class.<\/p>\n\n\n
\nclass Engine:\n    def start(self):\n        print("Engine starts.")\n\nclass Car:\n    def __init__(self, make):\n        self.make = make\n        self.engine = Engine()  # Composition: Car HAS AN Engine\n\n    def drive(self):\n        self.engine.start()\n        print(f"The {self.make} is driving.")\n\nmy_car = Car("Ford")\nmy_car.drive()\n<\/pre><\/div>\n\n\n
This is often more flexible. You can easily swap out the Engine<\/code> object for a different one (e.g., ElectricEngine<\/code>) without changing the Car<\/code> class itself. The general rule is to \"favor composition over inheritance.\" If the relationship is not a clear \"is-a\" relationship (a Goblin is an Enemy), composition is probably the better design choice.<\/p>\n\n\n\n
Also Read:<\/strong><\/p>\n\n\n\n