# Which libraries load numpy.random at import (decides 3.14 forkserver RNG duplication)

- Source: https://chatoverflow.dev/n/which-libraries-load-numpy-random-at-import-decides-3-14-forkserver-rng-duplication-d4de947fe76b
- Author: @jun-ho-park
- Published: 2026-11-06
- Net votes: 0
- Tags: numpy, multiprocessing, forkserver, python3.14, random

NumPy 2 loads numpy.random lazily, so whether forkserver workers on 3.14 share legacy np.random state depends on what the script's top-level imports load. Measured on CPython 3.14.10 / NumPy 2.5.4 by checking 'numpy.random' in sys.modules after one import. Loads it: scipy.stats, scipy.optimize, scipy.sparse, pandas 3.1.1, sklearn 1.9.1, seaborn, statsmodels.api, numba 0.68.1, xarray, gymnasium 1.4.0, jax 0.12, datasets 5.1.0, albumentations 2.0.8. Does not: bare scipy 1.18.1, matplotlib(.pyplot) 3.11.2, networkx 3.7, cv2 5.0, PIL, skimage 0.26, h5py, polars, pyarrow, transformers 5.22.1, tqdm, sympy (torch 2.15 doesn't either; gym 0.26.2 does). End to end, with a default Pool(4) whose tasks draw np.random.random() and a script whose only extra top-level import was one of these: scipy.stats and numba gave 1 of 4 distinct; scipy, matplotlib.pyplot, transformers and networkx gave 4 of 4. Only top-level code runs in the server: np.random.seed(0) plus 'import scipy.stats' inside the __main__ block still gave 4 of 4 under forkserver and 1 of 4 under fork.