Foundations — Inheritance — single inheritance, method resolution order (MRO)

This page assumes you have seen none of the words on the OOP Fundamentals parent. We build every symbol from the ground up, in the exact order they depend on each other.

1. What is an object? (the very first picture)

Look at the box in the figure. The data lives inside (name = "Rex"). The buttons on the side (speak()) are the behaviors. When you press a button, the object does something, often using its own inside data.

2. What is a class? (the blueprint the box was stamped from)

$\text{class}\stackrel{\text{stamp}}{\to }\text{object},\text{object},\text{object},\dots$

• The class is the cutter (exists once, describes the shape).
• Each object is a cookie (exists many times, holds its own values).

In the parent code, Animal is the class; d = Dog("Rex") makes one object d.

Cloze check:

3. The . (dot) — "reach inside / press a button"

• d.name → reach into d, read the data called name.
• d.speak() → reach into d, press the button speak, run it (the () = "press now").

The dot is the only way in the language to ask an object for something. Every hard question on the parent page ("which speak runs?") is really the question "where does the dot look?"

4. self — "the object I am attached to"

In the figure, three cookies (d1, d2, d3) share one speak recipe. When you press d2.speak(), inside that run self is d2, so self.name reads d2's name. Press it on d1 and self becomes d1. The recipe is written once; self swaps to whoever pressed the button.

5. __init__ — the "set-up on first stamp" button

class Animal:
    def __init__(self, name):   # runs at birth of the object
        self.name = name        # store the name INTO this object

• Animal("Rex") → Python stamps a fresh box, then runs __init__ with name="Rex".
• self.name = name → write "Rex" into this box's name slot.

6. __dict__ — "the class's private drawer of buttons"

Picture a labelled drawer per class:

• Dog.__dict__ contains speak (Dog wrote it).
• Dog.__dict__ does not contain __init__ (Animal wrote that one).

Cloze check:

7. Parent / child, and the arrow that stacks blueprints

The is-a test decides when to use it:

• A Dog is-a Animal → inherit.
• A Car has-a Engine → do not inherit; hold it as data (see Composition over Inheritance).

The figure shows the blueprint stack: Dog sits on top of Animal, which sits on object. An object of type Dog can reach every drawer below it.

8. object — the blueprint at the very bottom

So the stack never floats — it always lands on object. That is why the parent's chains always end ..., object. More at object — the root class.

$\text{Dog}\to \text{Animal}\to \text{object}$

Read \to as "inherits from / sits on top of."

9. Override and extend — two ways a child changes a button

To extend, you need one more tool.

10. super() — "the next blueprint down, please"

class Puppy(Dog):
    def speak(self):
        return super().speak() + " (tiny)"   # run Dog.speak, then add

• super().speak() → skip Puppy, take the next drawer with speak → Dog.speak → "Woof".
• then append " (tiny)".

11. The MRO list and __mro__ — the stack written out as a line

And the lookup rule that uses it:

In words: walk the line from the top; the first drawer that has the name wins; stop. If you fall off the end (object included) with no match, Python raises an AttributeError.

The general algorithm behind that formula is C3 Linearization; for single inheritance it collapses to "just the chain," which is all we need here.

Related ideas that ride on this same machinery: Polymorphism and Method Overriding (why the object's stack wins) and Encapsulation and Attribute Lookup (how data names use the same search).

Prerequisite map

Equipment checklist

Test yourself — cover the right side, answer, then reveal.

Ready? Every symbol above appears on the parent topic — you can now read it with nothing undefined. Prefer Hinglish? See 2.1.08 Inheritance — single inheritance, method resolution order (MRO) (Hinglish).