What causes Python's "Cannot create a consistent method resolution order" TypeError?

### What the error actually means At class creation the interpreter tries to produce a single linear order over the new class and all of its ancestors, subject to two constraints: * **Local precedence order** — the direct bases appear in the order written in the class statement. * **Monotonicity** — the new order is consistent with every base's own order, which in particular means no class ever precedes one of its own subclasses. If no sequence satisfies all of the constraints simultaneously, the algorithm has nothing valid to return, and Python refuses to build the class: ```python class A: pass class B(A): pass class C(A, B): # TypeError pass ``` The base list says A comes before B. B's own inheritance says B comes before A. Both cannot hold, so the class statement raises `TypeError: Cannot create a consistent method resolution order (MRO) for bases A, B` and no class object is created. Note *when* this happens: while the class statement runs — i.e. at import time for a module-level class — not when a method is called and not when an instance is made. A single bad base list can therefore take down a whole import. ### The two shapes you actually meet **A base listed before its own subclass.** Usually a refactor artefact: a class that used to be a sibling becomes a subclass, and a base list somewhere else silently becomes illegal. Consider a route-optimisation job whose planner mixes in an ETA formatter and a locale-dependent formatter. It worked while the two were independent; the moment the locale class is made a subclass of the plain formatter, `class Planner(Formatter, LocaleFormatter)` stops importing. The fix is mechanical: list the more derived class first, `class Planner(LocaleFormatter, Formatter)`, which is also the order that actually gives the specialised behaviour precedence. **Two bases that order shared ancestors differently.** ```python class A: pass class B: pass class X(A, B): pass class Y(B, A): pass class Z(X, Y): # TypeError: ... for bases A, B pass ``` Here neither base list is wrong on its own, but X insists A precedes B while Y insists the reverse, and Z would have to honour both. The error message names the pair of *ancestors* it could not order — A and B — rather than the bases you wrote, which is the single most useful piece of information in the message: it tells you exactly which two classes are in disagreement, not merely that something is wrong. ### How to diagnose it 1. Read the two class names in the message; they are the ancestors in conflict, not necessarily the classes in your base list. 2. Print the MRO of each base — `[c.__name__ for c in X.__mro__]` — and find where the two disagree about the relative order of the named pair. 3. If the conflict is "a class and its own subclass in one base list", reorder: derived first, generic last. 4. If two bases genuinely disagree about shared ancestors, no reordering of *this* class's bases can help — the contradiction lives upstream. Change one of the upstream base lists so the two agree, or stop inheriting from both and delegate to one instead. ### Why refusing is the right behaviour Python could pick some order and move on. It does not, because every alternative is worse: silently dropping local precedence would make base order meaningless, and silently dropping monotonicity would let a class be shadowed by the very base it overrides, so an override would vanish depending on which subclass you looked from. A loud failure at import beats a hierarchy whose behaviour changes by inheritance path, and it is a compile-time-ish guarantee: if the class object exists, its lookup order is coherent. One practical corollary: this error is a design signal, not just a syntax nuisance. Two bases that disagree about their shared ancestors have effectively been designed as alternatives to one another, and combining them is not a reordering problem. That is the point to consider holding one as an attribute and delegating instead of inheriting from both. ### Guarding against it Because the failure is at class creation, an import of every module is a complete check — no test needs to call anything. That makes it worth having a test that simply imports the package, especially in a codebase with mixins, since the classic trigger is a refactor elsewhere: one class quietly becomes a subclass of another and every base list that mentioned both in the old order becomes illegal at once. Before writing a base list with two related classes, `issubclass(B, A)` answers whether one must come first. And note what the error is *not*: it is not a name clash, not a complaint about diamonds — an ordinary diamond linearizes fine — and not something a metaclass fixes, since a metaclass conflict raises a different error about metaclasses entirely.