How does zero-argument super() know its class, and when does that fail?

### Two ingredients, both invisible `super()` with no arguments is not a plain function that inspects the stack by luck. It relies on a compile-time transformation plus a run-time frame read. **The `__class__` cell.** When the compiler sees the name `super` or `__class__` used inside a function defined in a class body, it makes that function a closure over an implicit cell variable named `__class__`, and arranges for the class statement to fill that cell with the class object it creates. The evidence is directly inspectable: ```python class A: def who(self): return "A" class B(A): def who(self): return "B->" + super().who() print(B.who.__code__.co_freevars) # ('__class__',) print(B.who.__closure__[0].cell_contents) # <class '__main__.B'> ``` **The first positional argument.** The receiver is not stored anywhere; `super()` reads slot zero of the currently executing frame. In a normal instance method that slot holds `self`; in a `classmethod` it holds `cls`. ### The two failures, and their exact messages Remove either ingredient and the call raises at run time, not at import time: - A function that is not lexically inside a class body has no cell: `RuntimeError: super(): __class__ cell not found`. - A function that has the cell but no first positional argument raises `RuntimeError: super(): no arguments`. Two ordinary constructs hit this: a `staticmethod`, which takes no receiver at all, and a helper function nested inside a method, whose own frame starts empty even though the cell is reachable through the enclosing scope. In both cases the fix is the explicit form. Inside a nested helper you already have `self` from the enclosing scope, so `super(B, self).who()` works; a `staticmethod` that needs the chain wants to be a `classmethod` taking `cls`, after which zero-argument `super()` works again. ### What the two arguments mean `super(C, obj)` reads as "start after `C` in `type(obj)`'s order, and bind `obj`". The first argument is the class the code lives in, never the class you want to reach — that is the single most common misreading. The second may be an instance, giving bound methods, or a class, giving the `classmethod` form `super(C, cls)`. Python validates the pair: if the second argument is neither an instance of the first nor a subclass of it, you get a `TypeError` saying exactly that, which is a useful signal that the two arguments were swapped. ### Why the cell beats writing the class name It is tempting to think `super(B, self)` and `super()` differ only in typing. They differ in what `B` means. The cell holds the class object the class statement built. The hand-written name is a global lookup performed at call time, and any decorator that returns a *different* class rebinds that global: ```python def wrap(cls): class Wrapper(cls): pass return Wrapper @wrap class B(A): def who(self): return "B" + super(B, self).who() ``` Here the global `B` is `Wrapper`, a *subclass* of the original class, so the search starts after `Wrapper` — which lands back on the original `who` and recurses until `RecursionError`. Written as `super()`, the same class works, because the cell still points at the class the body created. The same argument applies to class renaming, to classes built inside factory functions, and to any code where the name and the object can drift apart. ### One nuance worth knowing A class nested inside another class body gets its own cell for its own methods, so `super()` written in the inner class refers to the inner class, not the outer one. And since comprehension inlining in Python 3.12, a bare `super()` inside a list, set or dict comprehension in a method now works — the comprehension runs in the method's own frame — whereas a generator expression still creates its own frame whose slot zero holds the iterator being consumed, so a bare `super()` there fails. ### When you still write it out Explicit `super` has real uses beyond the failure cases: calling a chain from outside any class (a debugging helper, a migration script), or deliberately starting the search from a class other than the current one, which is rare and deserves a comment. Everywhere else, zero-argument `super()` is shorter, survives renames and decorators, and cannot get its own first argument wrong.