A telemetry collector's `__len__` scans a 2.4 GB buffer; why does `if collector:` trigger that scan?

### Why `if collector:` runs the scan at all Truth-testing an object is not free and is not special-cased. `if collector:` calls `bool(collector)`, which looks for `__bool__` on the type; the collector does not define one, so the interpreter falls back to `__len__` and treats the result as false only when it is `0`. Your `__len__` is the code that walks the 2.4 GB working set, so the emptiness check pays for an exact count it then throws away after comparing it with zero. A statement that reads like a null check is in fact a full traversal. The most common "fix" makes nothing better: `if len(collector) > 0:` calls the identical method. Nor does hoisting it out of the loop help if the loop is where emptiness changes. The cost is structural — the only cheap emptiness test is one the class provides. ### The fix: give the type a cheap `__bool__` `__bool__` short-circuits `__len__` entirely, so define it to answer the question actually being asked — *is there anything at all?* — with the cheapest evidence available: ```python class TelemetryBuffer: def __len__(self): # exact, expensive, rarely called return sum(len(chunk) for chunk in self._chunks) def __bool__(self): # cheap: stops at the first non-empty chunk return any(self._chunks) ``` `__len__` stays exact — `len()` is a promise and callers, `list()` and slicing logic depend on it — while every `if`, `while`, `not` and `and`/`or` in the codebase now takes the cheap path automatically, with no call sites edited. Other cheap sources of the same answer: a counter maintained on append and pop, a "first chunk" pointer, a `head is not None` check on a linked structure, or an EOF flag already tracked by the reader. If even that is not cheap, the honest move is to stop implying it is: drop `__len__` from the public shape, expose an explicit `has_readings()`, and let the object be plainly truthy so no implicit conversion can ambush you. When you want a rough size for pre-sizing rather than a truth value, `__length_hint__` — read via `operator.length_hint()` — is the hook that is *allowed* to be approximate. ### The second failure: the truth test can raise An expensive `__len__` is usually also a *fallible* one — it touches memory-mapped files, a spooled temp file, or a device handle. Whatever it raises propagates straight out of the `if` line, which is where the second half of this bug lives. Code shaped like ```python try: if collector: flush(collector) except Exception: pass # swallows the failure and the branch with it ``` turns a raised `__len__` into "the collector looked empty". Nothing is flushed, nothing is logged, and the readings are dropped silently — the classic swallowed exception, made worse because the implicit call is invisible in the source. Two disciplines contain it: never let a truth-conversion hook do work that can fail (a cheap `__bool__` reading an in-memory flag cannot raise), and never wrap a conditional in a bare `except Exception: pass`. If the emptiness check genuinely can fail, make the failure explicit with a method call that the reader can see, so the `try` block wraps something that looks like it might raise. ### Diagnosing it in a running service The symptom is a profile where a trivial-looking line dominates. Deterministic profiling (`cProfile`, or `sys.setprofile`-based tooling) attributes the time to `__len__` with a caller that contains no visible `len` call — that mismatch between the profile and the source is the tell. A sampling profiler shows the same stack. A cheap local check: add a `print` or a counter to `__len__` and run the code path once; if the count is far higher than the number of `len()` calls you can find by grepping, implicit truth tests are the difference. Because the scan touches the whole working set, the secondary damage is memory-behaviour rather than CPU alone — page faults and cache eviction across gigabytes, which is why the wall-clock cost is worse than the operation count suggests. ### What senior judgement sounds like here Say the mechanism first (`bool()` → `__bool__` → `__len__` → default true), then the fix at the type rather than at the call sites, then the invariant you are protecting: `__len__` stays exact, and `__bool__` may be an approximation only in the sense that it answers a coarser question. Add the operational point — a hook invoked implicitly must be cheap and must not raise, because callers cannot see it being called — and you have covered what the question is really testing.