What does hasattr() hide when a computed attribute raises AttributeError?

## hasattr runs code The common mental model is that `hasattr(obj, name)` asks a table whether a name is present. It does not. Its definition is operational: ```python try: getattr(obj, name) except AttributeError: return False return True ``` The attribute is *fetched*. For a plain instance attribute that is harmless. For anything computed — a `property`, a cached-lookup descriptor, a lazily materialised field — the code behind the name runs to completion, with all of its cost and all of its side effects, and its value is then thrown away. Two distinct problems fall out of that, and a good answer names both. ## Problem one: a broken attribute looks like a missing one Because the guard catches `AttributeError` without caring where it came from, an `AttributeError` raised *inside* the attribute's own body is reported as the attribute not existing: ```python class Transcript: @property def participants(self): raise AttributeError("backing store not loaded") hasattr(Transcript(), "participants") # False ``` Nothing about that `False` says a bug was swallowed. And the family is wider than a deliberately-raised error: any bug in the property body that itself surfaces as an `AttributeError` — calling a method on something that turned out to be `None`, a typo'd inner attribute name, a chained access through an object that failed to load — comes back to the caller as "the attribute is not there". Code guarded with `if hasattr(...)` then takes the it-is-absent branch, and the failure surfaces far downstream as missing data rather than as a traceback pointing at the real line. Three-argument `getattr` has exactly the same hole for exactly the same reason, so `getattr(obj, name, None)` is not a workaround. ## Problem two: it is not free, and it is not idempotent The `hasattr`-then-read shape computes the attribute twice: ```python if hasattr(obj, "summary"): use(obj.summary) # the property body runs a second time ``` If the attribute caches its result, the second run is cheap. If it does not — it queries something, reads a file, or advances an iterator — you paid twice, and any side effect happened twice. That is why the Python idiom for optional attributes is EAFP rather than LBYL: do the read inside `try/except AttributeError`, which performs one lookup, or use three-argument `getattr` when a default is genuinely acceptable and you have accepted the swallow above. ## What changed, and what did not On Python 2, `hasattr` caught *everything*: a `ValueError` or an `OSError` from a property also produced `False`. Python 3.2 narrowed it to `AttributeError` only, and that is still the behaviour on 3.14. So today the distinction is sharp and worth stating precisely in an interview: **the exception type decides**. A `ValueError` raised inside a property propagates out of `hasattr` and crashes the guard; an `AttributeError` becomes a quiet `False`. ## Doing it correctly The first fix is upstream, in the attribute itself: **do not raise `AttributeError` from a computed attribute to signal a failure.** Raise something the domain owns — a load error, a `RuntimeError`, a project-specific exception. Reserve `AttributeError` for the one thing the protocol means by it: this object does not provide this name. A lazy loader that raises `AttributeError` when its backing store is unavailable is actively lying to every reflective caller in the process. The second is choosing the right question at the call site. If you want to know whether the *instance* carries a stored attribute, ask the instance's dictionary directly — `name in vars(obj)` — which reads a mapping and runs no user code, at the cost of not seeing class attributes or computed ones. If you want to know whether the *type* declares the name at all without triggering it, `inspect.getattr_static(obj, name)` retrieves the raw attribute without invoking the descriptor protocol, so a `property` comes back as the `property` object itself rather than as its computed value. And if you actually want the value, take it with `try/except AttributeError` around the direct read, so the exception object is in hand for logging instead of collapsed into a boolean. ## The interview signal What separates a middle answer from a junior one here is not knowing that `hasattr` exists but being able to say *why* a `False` from it is ambiguous, and that the ambiguity is not a wart of the builtin but a direct consequence of using one exception type for both "no such name" and "the code behind that name failed". The senior version adds the operational half: in a long-running process, this class of swallow does not crash, it degrades — records ship without fields, and nothing in the logs points at the property that broke.