advanced35 minby DevFox

Attribute Lookup and the MRO

How Python finds an attribute, C3 linearisation, what super actually does in cooperative multiple inheritance, and what __slots__ changes about all of it.

Python

A mixin adds caching to your loader. Another adds logging. Both call super().__init__(), both work alone, and the class that uses both silently skips the logging one — because someone wrote Loader.__init__(self) instead of super().__init__() in a place that looked equivalent.

super() does not mean "call the parent". It means something more precise, and the difference only shows up with multiple inheritance, which is exactly when it is hardest to debug. By the end of this lesson you will know the order Python resolves attributes in, how that order is computed, what super() actually does, and what __slots__ changes about all of it.

The order

Every class has a method resolution order: the sequence of classes searched when an attribute is not found on the instance.

python

class Loader:
    def load(self): ...

class CachingLoader(Loader):
    pass

print(CachingLoader.__mro__)
# (CachingLoader, Loader, object)

Reading instance.load searches these in order, stopping at the first hit:

Data descriptors on the type
They win over the instance, which is the whole point of them.
The instance __dict__
Whatever was assigned to this particular object.
Each class in the MRO, in order
Where ordinary methods and class attributes are found.
__getattr__
Called only after all of the above have failed.

The same order from the descriptors lesson, with step three now expanded into the MRO

With single inheritance the MRO is the obvious chain. With multiple inheritance it is computed by an algorithm called C3 linearisation, and it guarantees three things:

A class comes before all of its bases
Bases appear in the order they were listed
The order is the same for every class in the hierarchy

Three promises, and a class statement that cannot keep all three does not compile

If no order can satisfy all three, the class statement fails immediately:

That is Python refusing to guess. C asks for A before B, but B is a subclass of A and must come first — there is no answer, so it says so at definition time.

The diamond

Loader appears once, after both subclasses, even though both inherit from it. That is what C3 buys: in a diamond, the shared base is initialised once, not twice.

What super() actually does

Now the sentence that matters: super() is the next class in the MRO of the instance's type, not the parent of the class containing the call.

In CachingLoader.__init__, super() is LoggingLoader when the instance is a PhotoLoader — a class CachingLoader knows nothing about and does not inherit from.

That is why super() is not a synonym for naming the parent:

Bad — calling the base class directly.

Good — following the chain.

The first version jumps straight from CachingLoader to Loader, skipping LoggingLoader entirely. So a PhotoLoader has no self.log, and the failure is an AttributeError somewhere far away — or worse, a logging mixin that quietly records nothing. CachingLoader looks correct in isolation and tests fine on its own; it only breaks in a combination its author never saw.

The second lets each class hand off to whatever comes next for this instance, which is the only way a mixin can work without knowing its siblings.

Designing for cooperation

Multiple inheritance works when every class in the chain follows the same contract:

Order matters where the work happens. Doing your part before super() means the most derived class acts first; after means the base acts first. For setup, after is usually right — the base's state exists before you build on it. For teardown, the reverse.

And the practical constraint that decides whether to use multiple inheritance at all: mixins should be orthogonal. Caching and logging do not interact, so any order works. Two mixins that both override load and both transform the result have an order-dependent outcome, and nobody reading class PhotoLoader(A, B) will realise it.

When they are not orthogonal, composition is the better tool — hold an object rather than inherit from it, as the foundations course put it, and then the order is written down as calls instead of implied by a base list.

Reading the resolution

Three things worth knowing how to inspect:

vars() versus dir() is the useful distinction. vars shows what this object itself holds; dir shows everything reachable, including inherited methods and dunders.

And the name-mangling rule, which surprises people:

A double leading underscore inside a class body is rewritten to include the class name. It is not privacy — it is collision avoidance, so a subclass defining its own __cache does not overwrite the base's. Use a single underscore for "internal"; use two only when you specifically need a subclass not to collide.

What slots changes

By default every instance carries a __dict__, which is what lets you add attributes at any time. __slots__ replaces it with a fixed set:

Two benefits and several catches.

The benefits: less memory — substantially, for millions of small objects — and attribute access is marginally faster, because slots are descriptors on the class rather than a dictionary lookup.

The catches, in the order they bite:

No __dict__, so nothing can add attributes later, and any code writing to instance.__dict__ — including the descriptor from the previous lesson — fails.

Inheritance undoes it. A subclass without its own __slots__ gets a __dict__ back, and the memory saving is gone. Every class in the chain must declare slots.

No class-level defaults for slotted names. __slots__ = ("width",) and width = 0 in the same body is an error, because the slot descriptor and the class attribute claim the same name.

Weak references need declaring. Add "__weakref__" to the tuple if anything will hold a weak reference to the instance.

Use it when you have measured a memory problem and have many small instances. @dataclass(slots=True) sets it up correctly for you, which is the least error-prone route.

A cheat sheet to keep

Where to go next

The object model is now complete: how an attribute is found, in what order, how super() walks a chain that is decided by the instance rather than the class, and what trading the instance dictionary away costs. The sentence to keep is the one about super() — most multiple-inheritance bugs are a class that named its base directly and worked fine until it was combined with something.

Next is The Import System, which moves from how a class finds its members to how your program finds its modules. It covers what import really does after the foundations course's summary — finders, loaders, sys.path, the caching that makes reimport a no-op, and why circular imports fail where they do.

Before you move on, build the diamond from this lesson and print its __mro__. Then change one super().__init__() to name the base directly, and confirm that one of the mixins stops initialising. Seeing the attribute vanish without an error is what makes the rule stick.