What does a Python class's `__mro__` tuple contain, and why does `object` end it?

### What is actually in the tuple `Cls.__mro__` is a `tuple` of class objects: `Cls` itself first, then all of its ancestors, then `object`. Three properties are guaranteed: 1. **Every ancestor appears exactly once**, no matter how many inheritance paths lead to it. A diamond's shared base is listed one time, not once per branch. 2. **The class itself is first**, so its own definitions always win over anything inherited. 3. **`object` is last.** In Python 3 every class derives from `object`, and the linearization rules forbid a class from appearing ahead of any of its subclasses; since `object` is a superclass of everything else in the tuple, the only position it can legally occupy is the final one. The tuple is computed once, while the class statement executes, and cached on the class. Attribute lookup that has to consult the hierarchy scans it left to right and stops at the first class whose own namespace contains the name. ### `__mro__` versus `mro()` ```pycon >>> class A: pass ... >>> A.__mro__ (<class '__main__.A'>, <class 'object'>) >>> A.mro() [<class '__main__.A'>, <class 'object'>] ``` `__mro__` is the cached tuple — read it when you just want to look. `mro()` is a method on the type that returns a new `list` each call; it is also the hook the machinery calls when it needs the order computed, which is why a metaclass can override it to produce a custom linearization. Because it hands back a fresh mutable list, mutating the result changes nothing about the class. `inspect.getmro(Cls)` returns the tuple and is the form to reach for in tooling, since it works uniformly for anything class-like. A detail worth having straight: `Cls.mro` is a method of the *metaclass*, so it is available on classes but not on instances — `A().mro()` fails unless the class itself defines such a method. `A().__class__.__mro__` or `type(a).__mro__` is the instance-side spelling. ### Reading a real one ```python from collections import OrderedDict [c.__name__ for c in OrderedDict.__mro__] # ['OrderedDict', 'dict', 'object'] ``` The practical habit is: when a hierarchy surprises you, print the MRO before theorising. It tells you, in one line, which class will supply each inherited name and where a cooperative call chain will go next. It is also the fastest way to spot an accidental base ordering — if a class you expected to specialise behaviour shows up *after* the generic base it was meant to override, the order, not the method body, is your bug. ### Why the shape matters Because the order is a total, linear order over all ancestors, questions that would be ambiguous in a raw graph become mechanical. "Which `__init__` runs?" is answered by scanning left to right. "What comes after this class in a cooperative chain?" is the next tuple element, and crucially that is a property of the *instance's* class, not of the class the code is written in — the same method body can hand off to different classes depending on whose MRO is in play. Two boundaries are worth naming. First, the MRO is about *classes*: an instance's own attribute dictionary is consulted first for ordinary attributes and does not appear in the tuple at all. Second, it lists what exists at class-creation time; classes created later that subclass `Cls` get their own tuples, and `Cls.__mro__` is unaffected. ### Failure mode The tuple is not merely descriptive — it is produced by an algorithm that can fail. If the constraints implied by the base list cannot all be satisfied, the class statement itself raises a `TypeError` and no class object is ever created, which is why you never see a malformed `__mro__`. Every tuple you can read is, by construction, a consistent one: class first, each ancestor once, subclasses before their bases, and `object` at the end. ### It is read-only, and it is a cache key `__mro__` cannot be assigned: `A.__mro__ = ()` raises `AttributeError: attribute '__mro__' of 'type' objects is not writable`. You cannot repair a hierarchy by rewriting the tuple, and you should not try — the supported way to influence the order is the base list, or a metaclass that overrides `mro()` before the class exists. CPython also keeps a per-type method cache keyed on this order, so the tuple's stability is what makes attribute lookup fast: the scan is short and its result is remembered until something in the hierarchy changes. A last detail that trips people: the tuple contains class *objects*, not names, so two same-named classes from different modules are distinct entries. Comparing MROs across a reload of a module will show classes that print identically but are not equal, which is usually the explanation when an `isinstance` check fails against a class that looks exactly right.