Why does `threshold = config.threshold or 92` ignore a configured 0, and what replaces it?

## The bug in one line `or` cannot tell "the caller supplied nothing" from "the caller supplied a falsy value". Both take the right-hand branch. So `threshold = config.threshold or 92` means *"use 92 unless `config.threshold` is truthy"*, while the author almost always meant *"use 92 unless the operator configured something"*. Every falsy legal value — `0`, `0.0`, `""`, `[]`, `{}`, `False` — is silently overwritten by the default. ## What it looks like in production A nightly report generator computes a 92nd-percentile latency budget and reads its knobs from a config object. Two of them are written with the `or` idiom: ```python class Config: def __init__(self, threshold=None): self.threshold = threshold cfg = Config(threshold=0) print(cfg.threshold or 92) # 92 -- the 0 vanished print(cfg.threshold if cfg.threshold is not None else 92) # 0 -- honoured ``` An operator sets `retries = 0`, meaning *do not retry this job*. `retries = cfg.retries or 3` turns that into three attempts. The failure is not the retry count itself; it is what the extra attempts do. Each aborted attempt of the report writer had already opened its temp output, and the abort path left that handle unclosed until the process exited, so a run that was configured to fail fast instead accumulated three open descriptors per failing job every night. The config file says one thing, the logs say another, and nothing raises — which is what makes this class of bug expensive rather than merely wrong. The same shape recurs with strings: `label = cfg.label or "unnamed"` erases a deliberately empty label, and `columns = cfg.columns or DEFAULT_COLUMNS` erases a deliberate `[]` meaning "emit no optional columns". ## The fix: ask the question you actually mean The narrow question is presence, and the operator for presence is `is None`: ```python threshold = cfg.threshold if cfg.threshold is not None else 92 ``` For mappings, `dict.get` already draws the distinction correctly — its default fires on a **missing key**, not on a falsy value — so the fix is to move the default into the lookup instead of after it: ```python settings = {"retries": 0} print(settings.get("retries") or 3) # 3 -- wrong print(settings.get("retries", 3)) # 0 -- right ``` `getattr(obj, "name", default)` behaves the same way for attributes. For function parameters, the idiomatic form is a `None` default plus an explicit `is None` test in the body, which keeps "caller passed nothing" separate from "caller passed zero". ## When `or` is still the right tool This is not a rule against `or`-as-default. It is correct — and more readable than the alternatives — whenever *every* falsy value genuinely should be replaced. `name.strip() or "anonymous"` is right, because an empty name and a whitespace-only name should both fall back. `parts = line.split(",") or ["<empty>"]` is right for the same reason. The decision is a single question asked per field: > **Is `0`, `""` or `[]` a legal, meaningful value here?** If yes, `or` is a bug waiting for the first operator who types a zero. If no, `or` is fine and concise. ## The mirror bug and its cousins `and` has the symmetric failure: `count = supplied and compute()` yields `0` rather than running `compute()` when `supplied` is `0`. And `if x:` used as a presence check is the same mistake in statement form — `if payload:` skips a legitimately empty payload that the protocol says must still be acknowledged, whereas `if payload is not None:` does not. Three habits keep this out of a codebase. **Review the field's domain, not the expression**: the `or` is only wrong when zero is meaningful, so the reviewable question is what the field can hold. **Type checkers help partially** — the result of `x or default` is typed as the union of both operand types, so a checker will flag `int | None` leaking through, though it cannot know that your `0` was intentional. **Test the boundary explicitly**: a test that passes `0` and `""` for every optional numeric and string knob catches the entire class in one pass, and is cheap to write. The semantics described here are stable across the whole Python 3 line and unchanged on **3.14**; there is no flag or future import that makes `or` distinguish absent from falsy.