I'll work on that PR to allow additional information at the end of the rng description.

quadratic_assignment is different. It's rng documentation is '2nd level' as part of the '1st level' options section. Does the decorator docstring patching cover that possibility? (I'm fine with leaving as-is)

Oh, I didn't notice before that rng is already the name of the argument. The reason for the two release cycles after rng is available as a keyword but before warnings are emitted is that downstream packages need to have access to to rng in their minimum supported SciPy. Since rng is already the keyword, we can actually begin to emit deprecation/future warnings immediately, if you'd like. Maybe take a look at the logic in the decorator and see what applies here?

Or I can, if you'd prefer.

Oh. And as you say, it's not even an argument; it's a key in a dictionary. Yeah, this would all have to be custom. Another option is to just not change this function. It is not tightly connected with anything else and probably not super widely used, so I would be content just leaving it alone.

I'll change the code to start emitting Warnings as per the SPEC-007 (rng is now available for all releases). The SPEC doesn't cover the case if rng is the keyword but it accepts RandomState

I propose:

• FutureWarning if rng is None and np.random.seed has been set.
• FutureWarning is rng is an int.
• DeprecationWarning if rng has been given a RandomState.

Yup, that sounds about right!

The failing tests are interesting. They're all from FutureWarnings from np.random.seed having been set, with rng not having been specified.
No global seed is now set in test_quadratic_assignment, it must be being set somewhere else.

If there is a global seed set, then this will cause complications as tests that just use 'rng'=None will all emit FutureWarning. This will be more of a problem down the line with the other SPEC-007 items mature.

I've had a quick search of the codebase. A global random seed is set in scipy/conftest.py. I think this is presumably set for (doc)testing purposes?

Perhaps there are other instances used elsewhere that are propagated into individual tests?

There is certainly an overabundance of setting np.random.seed in the codebase. This is a bad thing.

Alternatively it might be that examining np.random.mtrand._rand._bit_generator._seed_seq is None is not a good way for seeing if the global seed has been set.

I'm not sure about that part. Maybe we can unset it in relevant files? Or we just can't test that particular behavior in CI.

A global random seed is set in scipy/conftest.py. I think this is presumably set for (doc)testing purposes?

Indeed it is. This is historic, cf https://github.com/scipy/scipy/blob/main/scipy/conftest.py#L427.
Can probably be removed now that docstring examples have transitioned to using default_rng.

Feel free to push to the branch with the changes you'd like to see.

I've made the changes and have added extra tests to check that the warnings are emitted.