A video-metadata extractor calls `random.seed(1234)` at import; what does that do to the rest of the process?

## There is only one global generator The `random` documentation states it plainly: the functions the module exposes are bound methods of a hidden instance of `random.Random`, created when the module is first imported. `random.random`, `random.choice`, `random.shuffle`, `random.sample`, `random.randrange` and `random.seed` all operate on that one object. It is shared by every module in the process — your code, your dependencies, the framework, the client libraries. So `random.seed(1234)` executed at import time in a video-metadata extractor is not a local setting. It is a process-wide mutation performed as a side effect of importing a module, and it takes effect for whoever imports it, in whatever order imports happen to run. ## What the symptoms look like The extractor wanted reproducible frame sampling, and it gets it. So does everything else: * Retry and backoff jitter stops being jittered. Every worker that started from the same seed backs off on the same schedule, so a downstream dependency that a spread was meant to protect gets synchronised bursts instead. * Any sampling or A/B assignment built on `random` returns the same picks in every process. * The extractor's frame cache reports an 83% hit rate, up from a low baseline. That reads as a performance improvement in a dashboard, and it is really every worker requesting the same frame indices from the same videos — the sampling diversity the pipeline was designed around is gone. The diagnosis is made harder when the extractor swallows its own exceptions: the module that changed global state is precisely the module producing no error output, so nothing in the logs points at the import that caused it. When randomness "stops being random" across a fleet, grep for `random.seed` before anything else. ## The fix: own your generator ```python import random class FrameSampler: def __init__(self, seed=None): self._rng = random.Random(seed) # private state, nobody else touches it def pick(self, frame_count, k): return self._rng.sample(range(frame_count), k) ``` `random.Random(seed)` constructs an independent generator with its own state. Reproducibility is now a property of this object, not of the process. Libraries should never call the module-level `random.seed`; applications may, at the very top of `__main__`, and even then an explicit instance is clearer. If you must touch the global generator temporarily — in a test, say — bracket it with `random.getstate()` and `random.setstate()` so the previous state is restored, and note that `getstate` returns an opaque tuple describing the internal state, not a seed. ## Fork, workers and inherited state A forked child inherits the parent's generator state byte for byte, so two workers forked after the same seeding produce identical sequences. This is a classic source of duplicate "random" values across a worker pool. It matters less by default on 3.14 than it used to: the `multiprocessing` default start method is now `forkserver` on Unix other than macOS, while macOS and Windows use `spawn`, and both of those re-import `random` in a fresh interpreter which seeds from OS entropy. Choose `fork` explicitly and the inheritance is back — as it is for any hand-rolled `os.fork` usage. ## Two more things a senior is expected to add Threads share the instance too. Concurrent draws interleave against one state, so seeding buys you nothing reproducible once more than one thread is drawing — another reason per-component instances are the right unit. Reproducibility across Python versions has a narrow guarantee, and it is worth stating precisely: the documentation promises that `random.random()` will keep producing the same sequence for the same seed with a compatible seeder. The higher-level helpers built on top of it — `sample`, `choice`, `shuffle` — carry no such promise, so pinning a seed does not pin those results across upgrades. Persist the chosen indices if the selection itself must be reproducible years later.