Thanks for the suggestion. I'm good with derangements and distinct_derangements, but the range variant is probably out of scope for this library. If you can update the PR with those two in it, I'll include them in the next release.

Thank you! I have removed derangements_range.

For my understanding: is it out of scope because it doesn't take an iterable as input? If so, I think that makes sense, and I might look for a combinatorics package to include it in (or make one myself).

Your original issue gave a great motivating example - secret Santa - for the derangements. So that one I think makes sense to include. But the generalization I think is better suited for a more specialized library.

Ah, I think I had confused you by my later comment in the linked issue. The generalizations were not part of this PR but something I thought of afterwards and included as suggestion in the issue to discuss (and I agree with you that these generalizations would be out of scope here since there is not a documented definition of them).

On the other hand, the removed derangements_range function was just a utility function to generate classical derangements when the input is a range of numbers 0 to k, but faster than derangements. So derangements_range(k) == derangements(range(k)) for all k, but the default derangements function can also deal with input that is not just [0, 1, 2, 3], such as [0, 4, 13] or [0, 0, 1, 1] or ["blue", "red", 0, 1, -5]), at the sacrifice of being slower because of filtering permutations instead of making use of the assumptions that derangements_range does. (Edit: so the secret santa movitation applies to both derangements and derangements_range)

If that changes your mind, let me know, then I can add them back.