Why does a decorator factory called as @valid_until(time.time() + 3600) freeze one deadline?

### The timing model, stated precisely A decorator factory involves three calls at three different moments, and only one of them is per call: 1. The argument expressions in the decoration line are evaluated — once, when the `def` statement below them executes. 2. The factory runs with those values and returns a decorator — once, same moment. 3. The decorator runs with the function and returns the wrapper — once, same moment. 4. The wrapper runs — every call, forever after. For a module-level function, steps 1 to 3 happen during import, which for a long-running process means "once, at start-up". `time.time() + 3600` therefore produces a single float, at start-up, that is captured in the factory's closure and compared against on every subsequent call. Nothing recomputes it. The deadline is not a rolling hour; it is one instant, chosen at import. ```python import functools import time def valid_until(deadline): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): if time.time() > deadline: # `deadline` is a fixed float raise RuntimeError("deadline passed") return func(*args, **kwargs) return wrapper return decorator @valid_until(time.time() + 3600) # evaluated once, at import def plan_route(): return "planned" ``` ### What that looks like in production A route-optimisation job that imports once and then runs for days will pass its check for the first hour of the process and fail every call afterwards — or, with the comparison the other way round, never expire at all. Two workers started ten minutes apart carry two different deadlines from the same code, so behaviour depends on process age rather than on anything in the request. Restarts "fix" it, which is the worst property a bug can have. When the hosts' clocks disagree, the frozen value turns into a clock-skew artefact that appears to correlate with the machine rather than with the work: the same input succeeds on one worker and is rejected on another, and nothing in the request or the logs explains why. The same shape catches configuration. `@retry(times=int(os.environ["RETRIES"]))` reads the environment at import, which is before any code that wires configuration later in start-up has run; tests that set the value after importing the module see no effect at all, because the closure already holds the old one. A mutable factory argument is worse still — a list or dict passed as an option is one object shared by every call through that wrapper for the life of the process, so anything the wrapper mutates accumulates. There is a memory dimension too. Whatever you pass to the factory is reachable from the wrapper's closure for as long as the decorated function exists, which for a module-level function is the process lifetime. Hand a factory a preloaded lookup table and you have pinned a 2.4 GB working set that no call frequency, no garbage collector pass and no idle period will release. The decoration line is not where that cost is visible, which is what makes it a genuinely hard leak to find. ### The fixes Resolve late instead of capturing early. Pass a duration and compute the deadline inside the wrapper, or pass a zero-argument callable and call it per call: ```python def valid_until(deadline_fn): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): if time.time() > deadline_fn(): raise RuntimeError("deadline passed") return func(*args, **kwargs) return wrapper return decorator @valid_until(lambda: time.time() + 3600) def plan_route(): return "planned" ``` The generalisation: a decorator factory argument is a compile-time constant for your process. Pass values there when you *want* them frozen — a precompiled pattern, a lookup table you deliberately build once, a name used for a metric — and pass an indirection (a callable, a key into a settings object read inside the wrapper) when the value can change or must be observable in tests. ### The diagnostic habit When a value in a decorated path refuses to change until a restart, ask when the expression that produced it ran. "Once, at import" is the answer surprisingly often, and it applies to far more than decorators: default parameter values, class attributes, and module-level constants all share the same evaluate-once semantics. Decorator factories are just the place where the gap between "written next to a function" and "evaluated at import" is widest, because the decoration line reads like part of the call.