I think the proper fix for this would be to not do a full unguarded recursion in _coerce_to_uint32_array in the case of a sequence. We do not (intend to) accept nested sequences of any kind, just sequences of integers (or strings at that low level, but that was more of an abandoned, undocumented feature rather than a current feature). That way, we can avoid testing for the rare case and just raise an error when we actually encounter the rare case.

We're not in a rush to fix this, so I think it's worth getting right. If you are interested in carrying on with this, I welcome it. Here are a few notes to help prepare a PR for us:

• Please omit the unhelpful # --- OUR FIX --- comments. They can't be part of the final contribution to us. You may want to look into refining your AI setup so that it doesn't do that. Modern coding agent harnesses don't do that as much as just asking the chat interfaces does.
• Changes need tests added to the test suite.
• New functions, even if private, need docstrings (or at least comments) to help readers understand what they are for just as much as public functions do.
• There are a couple of ways to follow my implementation advice, but probably the best place to do it is inside of _coerce_to_uint32_array just before the recursion. The right exception (and message text) to raise is here.
• There's a related issue BUG: SeedSequence accepts types outside of spec #27380, and fixing both would make the PR more valuable.

Thank you!

Thank you for the feedback and clarification , will be looking forward to fixing both related issues within this PR

I just pushed an update that moves the recursion guard down into the C-layer like you suggested. It now intercepts nested sequences right before the recursion happens and throws the TypeError you linked. I also ripped out that old pure-Python check I had earlier, so the file is much cleaner now.
This should safely handle both the original infinite recursion bug and the invalid types from Issue #27380. I dropped a couple of tests into test_seed_sequence.py to lock it in, and they are passing locally for me.

Just pushed an update to fix this! I removed the local imports and that stray comment, and also cleaned up a few formatting issues and extra blank lines in the test file.

I was unaware that np.testing already had those assertion wrappers built in, so thanks for the heads-up. Everything is swapped over to use the global assert_raises and assert_raises_regex. Let me know if anything else needs tweaking

The lint check is failing on some formatting issues. Please run the linter before submitting.

https://github.com/numpy/numpy/actions/runs/28299255548/job/83847957504?pr=31775

The lint check is failing. Please run the linter before submitting the next fix.

Sorry for the back-and-forth on the linting. I’m still learning the specific automated check workflow. I've run the linter locally and verified the formatting now. Thanks for your patience.