How do data and non-data descriptors differ in Python's attribute lookup order?

### The classification rule Every descriptor is one of two kinds, and nothing about how you *use* it decides which: * **data descriptor** — its class defines `__set__` **or** `__delete__` (usually alongside `__get__`); * **non-data descriptor** — its class defines `__get__` and neither of the other two. A descriptor that defines `__set__` but no `__get__` is still a data descriptor; reads then fall through to the instance dictionary while writes are intercepted, which is a legitimate if unusual write-audit shape. ### The resolution order, in full `obj.attr` on an ordinary object runs `object.__getattribute__`, which does roughly this: 1. Search `type(obj).__mro__` for the name `attr`. Note whether anything was found, and what kind it is. 2. If it was found **and it is a data descriptor**, call its `__get__(obj, type(obj))` and return that. 3. Otherwise, if `attr` is a key in `obj.__dict__`, return that value untouched. 4. Otherwise, if the class attribute found in step 1 is a **non-data descriptor**, call its `__get__`. 5. Otherwise return the plain class attribute found in step 1. 6. If nothing was found anywhere, raise `AttributeError` — which is what invites the class's `__getattr__` fallback to run. Two things about that list are load-bearing. The **type is searched first, always** — the instance dictionary is never consulted before the class, it is merely preferred at step 3 over a *non-data* result. And the whole ordering exists to give a class the power to make an attribute non-overridable per instance, while keeping ordinary attributes cheap. ### Why it is arranged that way Methods are the reason. A plain function is a non-data descriptor, so a method must lose to the instance dictionary — otherwise you could never monkey-patch a single object's behaviour by assigning a callable to it, and every instance attribute would have to be checked against the class's method table first. Meanwhile, a computed or validated attribute must win, or every write would silently drop a plain value into the instance dictionary and permanently shadow the logic you installed. Making the split depend on `__set__` gives you exactly that: an attribute that only reads can be overridden, an attribute that manages writes cannot. ### What it looks like in practice ```python class Plain: # non-data: only __get__ def __get__(self, obj, objtype=None): return "from the descriptor" class Guarded(Plain): # data: adds __set__ def __set__(self, obj, value): raise AttributeError("read-only") class Reading: plain = Plain() guarded = Guarded() r = Reading() r.__dict__["plain"] = "from the instance dict" r.__dict__["guarded"] = "from the instance dict" r.plain # 'from the instance dict' -> step 3 wins r.guarded # 'from the descriptor' -> step 2 wins ``` Both instance-dictionary entries were written by hand, because the *ordinary* assignment `r.guarded = value` would have gone to `__set__`. That is the second half of the story: writes are handled by `object.__setattr__`, which calls the class attribute's `__set__` if it has one and otherwise writes into `obj.__dict__`. A data descriptor therefore controls both directions. ### The consequences interviewers are looking for **Shadowing.** `obj.method = lambda: ...` works and affects only that object, because methods are non-data. The same trick against a validated, `__set__`-bearing attribute either raises or is routed through the setter — the instance dictionary never gets a chance. **The caching pattern.** A non-data descriptor whose `__get__` stores the computed value under the same name in `obj.__dict__` is *skipped* on every subsequent access: the second lookup stops at step 3 and never calls `__get__` again. That is precisely why lazy-attribute descriptors are non-data by design; adding a `__set__` to one would silently destroy the optimisation and make every read pay full price. **Class-level access is a different path.** `Reading.guarded` goes through `type.__getattribute__`, which applies the same rules one level up: it searches the metaclass for a data descriptor, then the class's own MRO, and a descriptor found there is invoked with `obj=None`. **Debugging.** Because step 2 runs real code, `getattr` can raise or block; `inspect.getattr_static` walks the same structures without invoking anything, which is the right tool when you are trying to see what is actually installed. `vars(obj)` shows step 3's dictionary and nothing else, so an attribute that is visibly readable but absent from `vars(obj)` is a strong hint that a descriptor is producing it.