OK, I am fine with that. If we specifically do not fix this, I suppose we should add it to the notes section (assuming we do not support a bugs section, I am not sure) in the documentation.

Unless this is a bug in a branch that would (practically) crash before? In which case fixing it does not matter.

@rkern wrote

If this is a regression from 1.16, we can also restore 1.16 results.

The bug reported in #14457 is a regression from 1.16. The fix in #14458 fixes the bug, but also appears to introduce a change in behavior on systems where a C long int is 32 bits for inputs that are outside the range of a 32 bit integer.

I think it is fairly clear there is no NEP-19 problem here:

1. This is a regression, as the problematic code worked in 1.15, but does near-infinite hang now.
2. This fixes a potential segfault, as the bug involved dereferencing an int32 with an int64 pointer.
3. Arguably this does not affect the rng-stream at all. Rather, it affects the parsing of the input args to the function, so that the function returned the wrong number of samples or out-of-bounds values, and so should not have passed any downstream tests anyway.

Because of the delicacy of our back-compat guarantees on mtrand, it may be worth adding a release note though, even though I don't think we are breaking code that did anything useful before. (I checked: inputting args > 2**32 gave OverflowError before on 32-bit).

The note can go in doc/release/upcoming_changes/14465.changes.rst, mentioning that the args to hypergeometric are now treated as int64 on 32bit systems (or similar, however you think it should be described).

Because of the delicacy of our back-compat guarantees on mtrand, it may be worth adding a release note though, even though I don't think we are breaking code that did anything useful before.

Pretty clearly, gh-14458 did not change any useful behavior. If we want to be severely strict about not changing any behavior, however, we could revert gh-14458, and make the one-line fix that I mentioned in the comments to that PR. Then there would be no need for any mention in the release notes.

Just to make sure, 1.16.x also works?

@charris, the bug reported in #14457 was introduced in 1.17, so there should be no need to touch 1.16.x.

I don't think it is worth hassling over the new behavior. If an error was previously raised it is unlikely that anyone was depending on that behavior, but it might be good to have a note in case someone runs a new program on an old release.

Confirmed that 1.16.5 works, it gives an overflow error only (no bug).

I'll allow it since it's incidentally fixing a 1.17 regression (which crashes, to boot), but a similar enhancement would not fly otherwise.

@WarrenWeckesser could you add a release note which includes the changes in both this PR and gh-14458

My preferred change is actually reverting gh-14558 and fixing the original, actual bug. I'm closing this PR in favor of #14490.