okay there's quite a few other issues in the numpy.random docs, I'll see if I can send a fix today.

gh-14360 doesn't address everything yet, I just discovered that all np.random.<funcname> functions are missing from the docs.

Left to decide: there's still two namespaces left that look private:

• numpy.random.entropy (contains random_entropy and seed_by_array, unclear if those need to be public)
• numpy.random.bit_generator (contains only BitGenerator as a public object I think)

Left to do:

doc/source/reference/random/index.rst is missing links to numpy.random.<function> (e.g. np.random.seed, np.random.randn). They are completely missing from the docs.

• numpy.random.entropy (contains random_entropy and seed_by_array, unclear if those need to be public)

I'm not sure these are used anymore after moving to SeedSeq. They might be removable. The only advantage is that random_entropy ready system entropy to an ndarray. It predates Python 3.x only and so was needed since there wasn't a good way to universally ready entropy. IIRC entropy is read from random now.

entropy.random_entropy is still used by mt19937.pyx. SeedSequence uses randbits. Should we move entropy to _entropy or replace it with randbits SeedSequence().generate_state(RK_STATE_LEN) (mt19967 is legacy, but this is for the case where no seed is provided)?

Edit: use SeedSequence(), not randbits directly.

With that one change, then it could be removed.

numpy.random.random_integers and friends are documented via RandomState, i.e. via numpy.random.RandomState.random_integers. Since we would like to encourage people not to use these functions directly, I think this is preferable.

entropy.random_entropy is still used by mt19937.pyx. SeedSequence uses randbits. Should we move entropy to _entropy or replace it with randbits SeedSequence().generate_state(RK_STATE_LEN) (mt19967 is legacy, but this is for the case where no seed is provided)?

I think SS is the right idea here. Empty to not reproducible so might as well DRY here and remove entropy.

Is there a way to check that gh-14948 fixes scipy/scipy#10545?

Is there a way to check that gh-14948 fixes scipy/scipy#10545?

discussed with @mattip: this will fix it, let's just merge and then update SciPy after to use inter-sphinx links for the random functions again.

The Cython changes are the more interesting ones in this PR.

Going to close this as the fix has a 1.18 milestone.