What does a zero-argument super() call inside a method resolve to at runtime?

### The mistake the name encourages `super` reads like "the superclass", and in a single-inheritance tree that reading is never caught out. It is still wrong. A zero-argument `super()` call names no class at all. It builds a *proxy object* carrying two pieces of information: the class in which the executing method was defined, and the object the method was called on. Attribute lookup on that proxy walks the receiver's method resolution order — the flat tuple of classes in `type(receiver).__mro__`, fixed once when that class was created — and begins at the entry *after* the defining class. Because the walk uses the *receiver's* order, the class `super()` reaches depends on the runtime type of the object, which is not knowable when the method is written. ### The diamond that proves it ```python class A: def who(self): return "A" class B(A): def who(self): return "B->" + super().who() class C(A): def who(self): return "C->" + super().who() class D(B, C): def who(self): return "D->" + super().who() print([c.__name__ for c in D.__mro__]) # ['D', 'B', 'C', 'A', 'object'] print(D().who()) # D->B->C->A print(B().who()) # B->A ``` `B.who` contains exactly one `super().who()` call and it dispatches to two different classes. For a plain `B` instance the order is `(B, A, object)` and the entry after `B` is `A`. For a `D` instance the order is `(D, B, C, A, object)` and the entry after `B` is `C` — a class that appears nowhere in `B`'s bases and whose author `B` may never have met. That is the mechanism working as designed, not an accident: it is what lets `D` compose `B` and `C` into a chain in which every class runs exactly once, in one order, with `A` running once at the end. ### The two bindings Spelling the proxy out helps: read `super()` as "the defining class, plus this receiver". The defining class is a compile-time fact — the class whose body physically contains the method. The receiver is a run-time fact. Lookup then searches the slice of the receiver's order that follows the defining class, in order, through each class's own `__dict__`. Nothing about the defining class's base list enters that computation except through its position in the receiver's order. ### What cooperation demands The chain only holds if every class in it plays along. Each override must call `super()` rather than reaching for a named base, must accept the arguments its predecessors will pass, and must not assume it is last. If one class in the middle writes `A.who(self)` instead of `super().who()`, it hard-codes a jump to `A` and every class between it and `A` — `C`, in the example above — silently stops running. In an initializer chain the classic symptom is worse than a skip: when several branches each call a shared base explicitly, that base runs once per branch, so setup happens twice and the second run clobbers the first. ### It is not only about methods The proxy resolves any *class* attribute, running the descriptor protocol as it goes: `super().p` invokes the next `property` getter in the order, `super().x` reads the next class-level constant, and inside a `classmethod` a zero-argument `super()` binds the class rather than the instance. What it will never see is instance state — attributes assigned in `__init__` live in the instance `__dict__`, which the proxy skips entirely, because there is no "parent copy" of an instance to look in. ### When the search runs out If no class after the defining class supplies the name, the lookup fails like any other missing attribute: `AttributeError: 'super' object has no attribute ...`. `object` sits at the end of every order and defines very little, so a `super().save()` whose remaining order contributes no `save` raises rather than quietly doing nothing. That matters for optional hooks: if a step in the chain may or may not exist downstream, guard the call explicitly instead of assuming it degrades to a no-op. It is also the reason a truncated chain is so hard to notice — skipping a class that would have run is silent, while reaching the end of the order is loud. ### How to say it in an interview Two sentences carry the whole answer. `super()` answers "who is next", not "who is my parent". And the answer is a property of the instance, so a method written in one class can, and routinely does, dispatch into a class it has never heard of. Everything else — cooperative initializers, composable behaviour classes, the rule against naming a base directly — follows from those two facts.