OOP & Data Modelcritical

Method Resolution Order (MRO)

The order Python searches base classes when looking up a method or attribute in a class hierarchy.

Memory anchor

MRO = the seating chart at a family dinner. With multiple inheritance, Python uses C3 rules to decide who sits where — no one sits twice, and left-side family always comes before right-side.

Expected depth

Python uses C3 linearization (also called C3 MRO). Inspect it with ClassName.__mro__ or inspect.getmro(ClassName). In multiple inheritance, the order matters — Python searches left-to-right across base classes, depth-first but with local precedence. super() follows the MRO, not just the direct parent.

Deep — senior internals

C3 linearization ensures: (1) each class appears once, (2) base classes maintain their original order, (3) local precedence is preserved. The algorithm merges the MROs of all bases plus the base list itself. If a consistent linearization can't be found (e.g., conflicting order constraints), Python raises TypeError at class definition time. Mixins work because super() in each class calls the next class in the MRO — so a mixin's super() call chains correctly even though the mixin doesn't know what it'll be mixed with. This is cooperative multiple inheritance.

🎤Interview-ready answer

Python uses C3 linearization to compute the MRO — the order it searches classes for attributes and methods. You can inspect it with ClassName.__mro__. super() doesn't just call the direct parent — it calls the next class in the MRO. This makes mixins work correctly: each mixin's super() call chains to the next class in the resolved order. The algorithm prevents ambiguity — if two bases have conflicting orderings, Python raises TypeError at class creation.

Common trap

super() is not 'call my parent class'. It's 'call the next class in the MRO'. In multiple inheritance with mixins, that next class might not be what you expect. Always trace ClassName.__mro__ to understand the actual call chain.

Related concepts