A loader module reads os.environ at import time; why does patching the variable in the test change nothing?

### The scenario A clinical-lab result loader has a module that begins: ```python import os CUTOFF_HOURS = int(os.getenv("LAB_CUTOFF_HOURS", "24")) ``` A bug report says a 6,800-row batch was rejected wholesale because a few analyser timestamps arrived ahead of the server clock — a clock-skew artefact. You write a test that sets `LAB_CUTOFF_HOURS` to `0` to reproduce the strict-cutoff behaviour, and the loader behaves exactly as it always did. The patch is correct; it simply cannot reach the value. ### Why the patch cannot reach it Importing a module the first time runs its body top to bottom in a fresh namespace and then stores the module object in `sys.modules`. Every subsequent `import` of that name — from any module, in any test, in any order — finds it in that mapping and returns the same object without executing a single line of the body again. The module body is therefore a one-shot event whose timing you do not control: it happens at whichever import comes first, quite possibly during collection, before any test has run. `int(os.getenv(...))` is just an expression. Once it has evaluated, `CUTOFF_HOURS` is the number `24`. It is not a view onto the environment, not a lazy proxy, not a descriptor. Patching `os.environ` afterwards changes a mapping that nothing is going to read again. The same reasoning covers everything else people put in module bodies: a client object built from a URL, a connection pool, a compiled pattern that depends on a locale, a thread started at import, a handler registered into a global registry. Anything computed at import is frozen at import. ### The four responses, worst to best **Reload the module.** `importlib.reload(mod)` re-executes the body in the *existing* module namespace. It appears to work and quietly damages the suite. Every import-time side effect happens a second time — a second thread, a second registry entry, a second connection. Class statements build brand-new class objects, so instances created earlier keep the old ones: `isinstance(old_instance, mod.Record)` is now False, and `except mod.LoadError` stops catching the exception another module raises. Any module that did a from-import still holds the objects from the first execution, so half the process sees the old module and half the new one. Reload has legitimate uses in a REPL; in a suite it converts one order-dependent problem into several. **Set the variable before the first import.** This genuinely works, and it is what a runner-level startup file does. Inside a suite it is fragile: correctness now depends on which test imported the module first, which changes when tests are renamed, reordered, sharded or run in parallel. Treat it as a stopgap with a ticket attached. **Patch the module global.** `patch.object(lab_loader, "CUTOFF_HOURS", 0)` is honest, restores itself, and is order-safe. Its weakness is fidelity: you are asserting on a value you injected rather than on the code path that reads configuration, so the parsing, validation and defaulting logic in the module body is never exercised by any test. It is the right pragmatic answer for third-party code you cannot change. **Move the read to call time.** Make the module body definitions only, and read the environment inside the function that needs the value — or better, parse the environment once at a startup boundary into a small configuration object and pass it in as a parameter. Now the value is looked up when the call happens, `patch.dict` on `os.environ` works as expected for the boundary tests, and the tests below the boundary just pass a number. ### Diagnosing it in the wild The symptom is distinctive: a patch that provably applies (you can print the mapping inside the test) yet changes nothing. Check whether the name you are patching is read at call time or was evaluated during import. A quick scan of the module body for anything that is not a `def`, `class`, `import` or literal constant usually finds it in seconds. In a long-lived service, the same import-time computation also explains configuration that ignores a runtime change, and behaviour that depends on which entry point started the process. ### The rule worth stating Import should be cheap and side-effect free: definitions, and constants that depend on nothing outside the file. Everything that reads the world — environment, filesystem, network, clock — belongs behind a function the caller invokes, at a moment the caller chooses. That single convention removes this entire class of untestable module, and it also makes start-up time and import order stop mattering.