Why can't a method see a name bound in its own class body without self or the class name?

## Two different namespaces that look alike Executing a `class` statement creates a fresh namespace, runs the body's statements in it, and then hands that namespace to the metaclass to build the class object; the entries become the class attributes. Because assignment inside the body works normally, it is easy to assume the body behaves like a function scope. It does not, and the difference shows up the moment a `def` appears inside it. ## The rule: only function scopes nest Python's enclosing-scope chain is built from function scopes alone. When the compiler resolves a bare name inside a method, it walks outward through enclosing *functions* — and a class body is not one, so it is skipped. The search therefore runs: the method's own locals, then any enclosing functions (only if the class itself is nested inside a function), then the module globals, then the built-ins. The class namespace never appears in that list. ```python class Broken: RETRIES = 3 def limit(self): return RETRIES # NameError: name 'RETRIES' is not defined ``` The binding exists — as `Broken.RETRIES` — but it is reachable only through an attribute lookup, never as a bare name. ## Why the language does it this way If class namespaces did nest, every method would silently see every class attribute as a bare name, and adding an attribute to a class could quietly capture a name that a method was reading from the module. Attribute access would also become ambiguous with plain names, and inheritance would have to be folded into the lexical rules — a name inherited from a base class would have to become visible as a bare name inside a subclass's methods, at compile time, which is impossible because bases are only known at run time. Skipping the class body keeps name resolution decidable while compiling, and keeps `self.x` the single, explicit way to reach per-class state. ## What the class body itself can see Statements executed directly in the body are a different matter. They run top to bottom in the class namespace, so they see the names already bound above them, plus enclosing function scopes, module globals and built-ins. `DOUBLED = RETRIES * 2` immediately after `RETRIES = 3` is fine. A default-argument expression in a method signature also runs at class-definition time, in the class body, so `def limit(self, n=RETRIES)` works even though `return RETRIES` in the same method's body does not — one of the sharpest demonstrations of the boundary. ## Reaching the value properly Use `self.NAME` when subclasses should be able to override it: attribute lookup checks the instance dictionary, then the class, then each class along the MRO, so a subclass that rebinds the attribute changes what the inherited method sees. Use `ClassName.NAME` when you deliberately want the value defined on that specific class regardless of subclass overrides — note that this is an ordinary global lookup of `ClassName` followed by an attribute access, which is why it works even though the bare name does not. Inside a `classmethod`, `cls.NAME` gives you the subclass-aware version. ## The one compiler-provided exception A method that mentions zero-argument `super()` or `__class__` gets an implicit closure over the class being defined, inserted by the compiler specifically to make `super()` work. That is a targeted compiler mechanism, not the class body acting as an enclosing scope; every other name in the method still skips the class namespace. ## The interview shape Expect to be shown a small class where a method reads a class attribute as a bare name and asked what happens. Say `NameError`, name the rule (only function scopes nest; class bodies are skipped), point out that the value is genuinely there as a class attribute, and give both fixes with the reason to prefer `self.` — subclass overrides. Mentioning that code directly in the body *can* see earlier names shows you understand the boundary rather than having memorised a gotcha.