Foundations — `super()` — calling parent methods

Before you can read the parent page on super(), you need to be fluent in a small pile of words and symbols it throws around casually: class, object, method, self, inheritance, overriding, MRO, and the dotted notation like Dog.__mro__. This page builds every one of them from zero, in an order where each depends only on the ones before it.

0. What is a "class" and what is an "object"?

Picture a cookie cutter and the cookies. The cutter is the class — one shape, drawn once. Each cookie stamped out is an object — many, all sharing the shape but each its own physical cookie.

Why the topic needs this: super() only ever appears inside a class, and it always acts on behalf of one object at a time. If "class vs object" is fuzzy, every later sentence is fuzzy.

class Animal:      # the blueprint (class)
    pass
 
a = Animal()       # a is one real thing (object / instance)

1. Attributes and self — the object's own pockets

Look at the figure: two cookie objects, each with its own name pocket. When a method runs "on Rex", self points at Rex's box; when it runs "on Milo", self points at Milo's box. Same code, different pocket.

Why self and not something automatic? Because one blueprint serves many objects. The method needs a way to say "this particular object's name", and self is that pointer.

2. Method — an action stored in the blueprint

The picture: the blueprint (class) has a little toolbox drawn on it. Each tool is a method. Every cookie built from the blueprint gets to use those tools, and each tool automatically knows which cookie it's working on (that's self).

Why the topic needs it: super() is entirely about methods calling other methods. The star example is a special method called __init__.

3. __init__ — the "set-up" method

Picture a brand-new blank cookie coming off the cutter, then a hand immediately writing its name and number of legs on it — that hand is __init__.

class Animal:
    def __init__(self, name):   # runs when Animal(...) is created
        self.name = name        # fill the 'name' pocket
        self.legs = 4           # fill the 'legs' pocket

Why it matters: the entire parent page's Worked Example 1 is about two __init__ methods (parent and child) cooperating. You cannot follow that without knowing __init__ is the auto-run set-up step. See `__init__` — constructors.

4. Inheritance — one blueprint built on top of another

The picture: a family tree drawn downward. Animal sits on top; an arrow points down to Dog. Dog automatically owns everything Animal had, plus whatever new it declares.

Why the topic needs it: super() has no meaning without a parent to reach up to. Inheritance is the ladder; super() climbs it. Full detail lives in Inheritance — extending classes.

5. Overriding — the child re-writes a method it inherited

Picture the family tree again: Animal has a speak tool, and Dog draws its own speak tool right over it. For a Dog object, Python reaches for the closer (child) tool first.

This is the exact gap the whole parent topic fills. Contrast override vs overload in Method Overriding vs Overloading.

6. The dotted notation Dog.__mro__ and the tuple output

Before the parent page's HOW section, it shows:

Dog.__mro__   # (Dog, Animal, object)

Two symbols to decode:

7. MRO — the search order, drawn as a queue

Picture a line of people, each holding a copy of the same toolbox. You walk the line asking "do you have a speak tool?" and take the first "yes." For Dog: the line is Dog → Animal → object.

Now the parent page's central equation reads like plain English:

Prerequisite map

When inheritance is the wrong tool

One honest note the parent page hints at: not every "reuse" needs inheritance and super(). Sometimes an object should just hold another object and call its methods. That alternative is Composition over Inheritance — worth knowing so you don't force a family tree where none belongs.

For a walkthrough in a mix of Hindi and English, see the Hinglish version →, then return to the parent `super()` — calling parent methods page.

Equipment checklist