Thanks for the ping. I suppose if I'm here, I'd suggest using one of the legacy names for the keyword unless it is going to follow the SPEC 7 plan. If this keyword is intended to be permanent, a different name might be helpful to signal different behavior from the ecosystem standard; if not (if the library wants to adopt the standard some day, but not yet), it's easier to replace the keyword than to change an existing keyword's behavior in backyard compatible way.

Codecov Report

Attention: Patch coverage is 66.66667% with 5 lines in your changes missing coverage. Please review.

Project coverage is 64.68%. Comparing base (a2bad17) to head (82ed3f3).

@@            Coverage Diff             @@
##           master    #3945      +/-   ##
==========================================
+ Coverage   64.67%   64.68%   +0.01%     
==========================================
  Files          92       92              
  Lines       12862    12873      +11     
==========================================
+ Hits         8318     8327       +9     
- Misses       4544     4546       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@CloseChoice @connortann I've revised in the following ways, let me know if you'd like any other changes:

• I ignored two testsuite mypy complaints related to NumPy get_state(), which may have caused confusion because it has a return type that is variable based on a modern or legacy mode, and mypy picked the incorrect one for whatever reason
• Based on Matt's feedback, I switched away from the rng keyword to make it easier for the shap team to properly adopt SPEC 7 in the future if that ever becomes desirable. I went with seed instead, though it is admittedly slightly annoying to have an argument called seed that doesn't accept an integer and only a Generator. We could try to add support for integer as well, although scope creep perhaps...
• I rebased on latest master and pytest --import-mode=append still seems happy locally at least

Thank you @tylerjereddy for the PR and for bringing SPEC 7 to our attention. It is fantastic to have you as a contributor.

I think it would make sense for shap to move towards adopting SPEC 7, and I'm happy to work on making that happen (related: #3980). The good news is that we don't have an existing seed argument to handle (in this case), so the transition should be a bit simpler than in the reference implementation in the SPEC.

I think we should introduce the new rng parameter immediately, rather than seed which to me suggests an integer. I like your suggestion of maintaining backwards-compatibility for now. How is this as a transition plan:

Initially:

• Add the new rng parameter, which if provided will be normalised as per SPEC 7.
• If the global seed is set, raise a FutureWarning that the future behaviour will change

Then in future:

• Remove use of the global state, and just use rng = np.random.default_rng(rng).

The initial change could be implemented as:

def my_func(*, rng=None):

    if rng is not None:
        # If rng argument is provided, normalise as per SPEC 7
        rng = np.random.default_rng(rng)
    else:
        # Otherwise, maintain backwards compatibility for now, raising a warning if the global seed was set
        global_seed_set = np.random.mtrand._rand._bit_generator._seed_seq is None
        if global_seed_set:
            msg = (
                "The NumPy global RNG was seeded by calling `np.random.seed`. "
                "In a future version this function will no longer use the global RNG. "
                "Pass `rng` explicitly to opt-in to the new behaviour and silence this warning."
            )
            warnings.warn(msg, FutureWarning, stacklevel=2)

    # Example use
    inds = np.arange(10)
    if rng is None:
        # For now, maintain backwards compatibility.
        np.random.shuffle(inds)
    else:
        rng.shuffle(inds)
   

Then at some point in future we'd just have:

def my_func(*, rng=None):
    rng = np.random.default_rng(rng)
    
    inds = np.arange(10)
    rng.shuffle(inds)

PS - @tylerjereddy you might be interested in the contributor discussion #3559