Why can Python's built-in hasattr() report False for an attribute that is genuinely defined?

### What hasattr actually does It is tempting to read `hasattr(obj, 'total')` as "is `total` present in the class or instance dictionary?". It is not. The builtin is specified in terms of `getattr()`: it calls `getattr(obj, name)`, returns `True` if that returns, and returns `False` if it raises `AttributeError`. Every mechanism that participates in attribute lookup therefore runs: descriptors, `property` getters, `__getattr__`, `__getattribute__`, and any `__slots__` or metaclass machinery involved. Two consequences follow, and both are the reason this LBYL guard is unreliable even in a single-threaded program with no races anywhere. ### Consequence 1: the check has the cost and the side effects of the operation If `total` is a `property` that queries a database, walks a large structure, or lazily builds a cached value, then `hasattr(invoice, 'total')` does that work — and if you then read `invoice.total`, you have done it twice. If the getter has side effects, the "check" performs them. A guard is supposed to be cheaper and safer than the operation; here it *is* the operation, plus a discarded result. ### Consequence 2: it confuses "absent" with "the getter is broken" This is the interview point. Consider: ```python class Invoice: @property def total(self): return self._rows.total # _rows was never set ``` Reading `invoice.total` raises `AttributeError: 'Invoice' object has no attribute '_rows'` — a real bug, with a real traceback pointing at the line. But `hasattr(invoice, 'total')` catches that `AttributeError` and answers `False`. Calling code written as `if hasattr(invoice, 'total'): use_it()` silently takes the "no total" branch. The feature quietly stops working, no exception ever surfaces, and the traceback that named `_rows` is gone. The same trap appears in any `__getattr__` implementation that computes something and can raise `AttributeError` from within, and in property chains where a nested access fails. Note the precise scope of the swallowing: **since Python 3.2, `hasattr()` swallows only `AttributeError`.** A `ValueError` or `TypeError` from the getter propagates out of `hasattr()`, which surprises people who expect a boolean function never to raise. On Python 2 `hasattr()` caught *every* exception, which was worse; the 3.x behaviour is a narrowing, not a fix, because `AttributeError` is exactly the type these bugs raise. ### What to use instead **Attempt the operation and catch AttributeError around the use.** This is the EAFP form, and it is the one that keeps the distinction, because the exception object and traceback survive: ```python try: total = invoice.total except AttributeError: total = None ``` This has the same masking property in the narrow sense — the broken getter still raises `AttributeError` — but it fails at the point of use with the real traceback available in the handler, and it makes the swallowing explicit and greppable rather than hidden behind a boolean. **Use getattr with a default when you want a value, not a boolean.** `getattr(obj, name, default)` is one lookup instead of two, and expresses the intent directly: ```python total = getattr(invoice, 'total', None) ``` A unique sentinel (`_MISSING = object()`) distinguishes "absent" from "present and equal to `None`". **When you are checking a shape, not a value, do it structurally.** Repeated `hasattr()` calls to establish that an object "looks like a renderer" are a hand-rolled interface check that runs getters and answers at one instant in time. `typing.Protocol` expresses the required shape for a static checker, and `typing.runtime_checkable` allows an `isinstance()` test against it for the method-presence case. Better still, in most Python code, is to call the method and let the failure be a `TypeError` or `AttributeError` with a traceback that names the offending object. **When you really do mean "is this name defined on the class"**, ask that question instead of the attribute-access question — inspecting the class hierarchy's dictionaries answers about definition without executing any getter. ### Why this belongs in the EAFP discussion The filesystem case shows a look-before-you-leap check going stale because the world changed between the check and the use. `hasattr()` shows something sharper: the check can be **wrong at the moment it runs**, because it is not asking the question you think it is asking. Both push the same conclusion — a guard is an approximation of the operation, while attempting the operation is the operation. The guard may inform a decision; it should never be the reason you believe the following line is safe.