In a nightly report generator a computed @property re-reads the clock on every access, so two fields in one row disagree — when is a property the wrong tool?

### The contract a property signs `obj.total` and `obj.total()` are the same amount of work to the interpreter and very different promises to the reader. Parentheses say *something happens here*; a bare attribute says *this is a value the object has*. Every convention built on top of Python assumes the second reading: debuggers evaluate attributes to populate a variables pane, `repr` implementations touch them, serializers and template engines walk them, and `hasattr` calls them speculatively. A property that violates the promise does not fail at its definition — it fails scattered across the callers who trusted it. The nightly report is the canonical shape. A getter written as `return time.monotonic() - self._started` is correct in isolation and wrong in aggregate: the header and the footer of a single row each read it, get two different clock samples, and the report shows an internally inconsistent row. Nobody wrote a bug; the attribute simply is not a value, it is a measurement, and measurements need an explicit moment. ### The four properties that are the wrong tool **Volatile.** The getter depends on something outside the object's stored state — the wall clock, a monotonic clock, `random`, a mutable global, an environment variable, the contents of a file. Two reads legitimately differ, and any caller that reads twice gets an inconsistency it cannot see in the source. Fix by freezing the volatile input: capture it once, store it (`self._as_of`), and let the getter be a pure function of stored state. If the moment belongs to the *operation* rather than the object, pass it as an argument to a method — `row.age_at(as_of)` — so the caller owns the reference point and all rows in a report share one. **Expensive.** The getter loops over a large collection, walks a graph, formats a document. This is invisible at the call site, so it lands inside other people's loops. Under a 1,200-request-per-minute peak, one hidden recomputation per field per row becomes a profile you cannot explain from reading the calling code. Two escapes: promote it to a method with a verb name (`compute_totals()`) so cost shows, or — if the value truly is stable for the object's lifetime — store it once with a caching descriptor such as `functools.cached_property`, accepting the invalidation problem that comes with it. **Fallible.** A getter that raises breaks things quietly. `hasattr(obj, "x")` catches only `AttributeError`, so a getter that raises `AttributeError` internally — including from a typo inside it — makes `hasattr` return `False` and the caller conclude the attribute does not exist. Any other exception propagates out of `hasattr` instead, which surprises callers the other way. Worse, a raising getter makes objects hostile to debuggers and `repr`: you cannot inspect the object without triggering the failure. Anything that can fail meaningfully should be a method that raises a documented exception at an explicit call. **Side-effecting.** A getter that mutates, logs, increments a counter, or lazily opens a connection turns *reading* into *doing*. Debugger inspection then changes program state — the worst class of heisenbug, because the act of looking is the act of changing. ### What I would actually change in this report Bind one `as_of` at the top of the run and thread it down: rows compute against a value they were given, so every field in every row of one report shares a single reference point, and re-rendering a row produces identical output. That also makes the whole thing testable — pass a fixed `as_of` and assert exact numbers, with no clock patching and no tolerance windows. Keep `age_seconds`-style attributes only where the underlying inputs are stored on the object; where the answer depends on *when you ask*, make the asking explicit. ### Diagnosing it in an existing codebase Profiling finds these: a deterministic profiler attributes time to the getter function by name and file line, so a getter high in the profile with a call count far above the object count is a hidden recomputation. The other signal is a diff in output between two runs over identical input — for a report generator, running the same input twice and comparing bytes catches every volatile getter in one shot, which is worth wiring into a test. ### The rule, compressed Use a property when the value is a cheap, repeatable, exception-free function of state the object already holds, and when there is a real reason not to expose a plain attribute — validation, a derived view, a name you want to keep stable while the storage changes. Use a method the moment reading costs something, might fail, might change, or depends on when you asked.