When does Python try the right operand's __radd__ before the left operand's __add__?

### The default, and the one exception to it For a binary operator the usual order is left-operand first: `left + right` asks `type(left).__add__` and only consults `type(right).__radd__` when the first call returns `NotImplemented`. There is exactly one documented exception. **If `type(right)` is a proper subclass of `type(left)` *and* it overrides the reflected method, Python calls the reflected method first.** Both conditions matter, and candidates usually remember only the first: ```python class Interval: def __add__(self, other): return "Interval.__add__" class Exon(Interval): def __radd__(self, other): return "Exon.__radd__" class Gap(Interval): pass Interval() + Exon() # 'Exon.__radd__' subclass overrides -> reflected first Interval() + Gap() # 'Interval.__add__' no override -> ordinary left-first order ``` "Overrides" is checked against the left operand's type: the right type must supply a reflected method that is not the same object as the one the left type would use. A subclass that merely inherits the base's `__radd__` — or defines nothing at all — does not qualify, and the ordinary left-first order applies. ### Why the rule exists It is a specificity rule, and the argument is about time. A base class is written before its subclasses exist, so `Interval.__add__` cannot know what an `Exon` is; it will either produce a plain `Interval` (silently downgrading the more specific type) or blindly succeed with the wrong semantics. The subclass, by contrast, was written *knowing* the base, so it is the only one of the two that can make an informed decision. Python therefore gives the more specific type first refusal whenever it has bothered to express an opinion by overriding the reflected method. The pattern generalises: whenever a subclass wants different behaviour with a base instance on the **left**, `__radd__` (and its siblings) is the hook, because `__add__` on that expression belongs to the base. ### Living with the rule as an author Three consequences worth stating out loud: * **Your override wins, so it must be able to lose.** A reflected method that always returns a result silently pre-empts the base class for every mixed expression. If your subclass only wants to handle some cases, return `NotImplemented` for the rest — Python then falls back to the base's `__add__` exactly as it would have without the override. * **The order flips depending on which side you are on.** `base + sub` reaches your `__radd__` and `sub + base` reaches your `__add__` (inherited or not). A subclass that handles one direction and forgets the other produces an asymmetric operator, which is a hard bug to read in a traceback because the two expressions look symmetric on the page. * **Same-type operands skip reflection entirely.** For two instances of one class the reflected method is not consulted at all: `__add__` runs once, and a `NotImplemented` return goes straight to `TypeError: unsupported operand type(s)`. The subclass rule needs *different* types, one a proper subclass of the other, before it can fire. ### How CPython decides At the C level the arithmetic dunders of a Python-defined class share a single slot function, so before it swaps the order the interpreter has to check whether the right operand's type genuinely supplies a different reflected method than the left operand's type would — the "overrides" test above. If the left type has no such method at all and the right type does, that also counts as an override. Only then are the operands swapped for the first call. If the reflected call returns `NotImplemented`, the interpreter falls back to the left operand's ordinary method, so the subclass never loses the base's behaviour by declining — it only loses it by returning a wrong answer. ### Why it comes up in interviews The rule is genuinely obscure, so it is rarely a gate. It is asked as a probe: it separates people who have read the data-model chapter and reasoned about operator dispatch from people who have only written `__add__` once. The answer an interviewer is listening for is not the C-level mechanism but the *design* claim — the more specific type gets first refusal, because it is the only one that can have been written with knowledge of the other — plus the discipline that follows from it: return `NotImplemented` from an override whenever you want the base class's behaviour back.