Why does every `concurrent.futures.InterpreterPoolExecutor` worker re-import your modules?

### The mechanism A `concurrent.futures.InterpreterPoolExecutor` worker is an OS thread running its own interpreter, and `sys.modules` is per-interpreter state. The mapping starts nearly empty — a fresh interpreter carries only the frozen bootstrap modules — so the first task that touches a module triggers a full import in that worker: find the source, execute it top to bottom, bind the resulting module object into *that* interpreter's `sys.modules`. Do it again for the next worker. Nothing the parent imported is visible, and nothing one worker imports is visible to another. That is the same isolation that gives the pool its parallelism. It is not a bug to route around; it is the deal. ### Cost one: startup Creating an interpreter is cheap in absolute terms — single-digit milliseconds — but the import graph on top of it is not bounded by anything except your dependencies. A worker that ends up importing a deep tree of packages can spend hundreds of milliseconds before its first task runs, and it pays that once per worker, not once per process. For long-lived pools this amortises away. For a pool created per request, or a pool of many workers running short tasks, it can dominate the wall clock and quietly undo the parallelism you switched for. The executor accepts an `initializer` callable that runs once in each worker interpreter, which is the designated place for per-worker warm-up rather than doing it lazily inside every task. ### Cost two: duplicated module state, and the configuration trap Every module-level object exists once per worker. A cached lookup table, a compiled pattern set, a memoised reference map: N workers, N copies, N times the memory. That changes how you size `max_workers` — with a thread pool the cache is shared and worker count is nearly free memory-wise; here each worker carries the full weight. The sharper failure is configuration. Consider a payment reconciliation job that, at startup in the parent, reads an environment setting and rebinds a module-level amount-format constant to a grouped, locale-dependent form. On a thread pool that just works: one interpreter, one module object, everybody sees the mutation. Move to an interpreter pool and the workers import that module fresh and get its **import-time default** instead. Nothing raises. The job runs, and at a 1,200-request-per-minute peak it writes hundreds of thousands of amounts in the wrong format, discovered downstream by whoever consumes the file. ```python from concurrent.futures import InterpreterPoolExecutor SEEN = 0 def count_row(): global SEEN SEEN += 1 return SEEN if __name__ == "__main__": with InterpreterPoolExecutor(max_workers=1) as pool: print([pool.submit(count_row).result() for _ in range(3)]) print("main interpreter still sees:", SEEN) ``` The worker counts 1, 2, 3 in its own copy of the module global; the parent still reads 0. Any design that treats a module global as shared mutable state is broken by the move, and it is broken silently. The fix is a discipline, not a workaround: **make configuration an explicit argument**, part of the task's input rather than ambient module state. Anything that must be established per worker goes in the executor's `initializer`. Anything that is genuinely global — a feature flag, a format setting — is read from process-level state such as `os.environ`, which *is* shared, or passed with every task. ### Cost three: extensions that refuse to load A native extension module has to opt in to being loaded in more than one interpreter. One that has not simply refuses, and the import raises an error saying that the module does not support loading in subinterpreters. In the stdlib, `readline` is an example. In the wider ecosystem, plenty of compiled packages are still in the process of adding support. This is the constraint that decides adoption, and it is discovered late if you do not go looking: the pool works fine in a unit test that imports nothing heavy, and fails the first time a real task pulls in the dependency. Test the actual import graph in a real subinterpreter before you commit. ### Diagnosing it in a running service Symptoms cluster. Throughput that improves far less than the worker count suggests, with CPU low: suspect import time per worker — have a task report how long its first import took, or the size of its `sys.modules`. Memory that scales linearly with `max_workers`: suspect duplicated module-level caches. Results that are subtly wrong only under the pool, never under a thread pool or in tests: suspect configuration that the parent mutated at runtime and the workers never saw. Import errors under load but never in development: suspect an extension without subinterpreter support on a code path only production reaches. ### The framing to offer Per-worker module state is the price of the per-interpreter GIL, and it is the same price a process pool charges — you were already paying it there. What is new is the temptation to forget, because the pool lives in one process and *looks* like a thread pool. The senior habit is to treat every task as if it ran in a fresh interpreter, because it does.