`seed_everything` should crash if invalid seeds are provided

[jonathanking]

Description & Motivation

Hi all,

I'd like to follow up on post-merge thread from #18846:

Current behavior
seed_everything has the behavior of changing the seed to 0 if the user provides an integer seed outside of numpy's acceptable range [0, 2**32-1].

Potential Issue
When the user calls pl.seed_everything(X), where X is outside of the acceptable range, they expect that it is seeded with this value. Instead, a warning is printed, and the code proceeds with seed 0.

I think this behavior is dangerous. If the user provides a seed that is out-of-bounds, this is a user error, and it is safer to raise a ValueError than it is to proceed with something that does not match the user's expectation. In this case, the user desires to set the seed to X. Why would they be ok with using the default seed of 0?

Looking forward to hearing any feedback. Thank you!

Pitch

Proposal
Raise a ValueError if the user specifies a seed to pl.seed_everything that is outside of numpy's acceptable range. This would cause programs to crash if they specify a seed that is out-of-bounds. I argue that out-of-bounds input to pl.seed_everything should be handled in a way that matches user expectations.

Alternatives

No response

Additional context

No response

cc @lantiga @Borda

[deependujha]

I see your point about silently falling back to 0 being misleading.

My concern is that raising a ValueError now could break workflows relying on the current behavior.

[jonathanking]

Thanks for bringing this up. I understand the concern about breaking workflows that rely on the current fallback, but I think raising a ValueError for out-of-bounds seeds would ultimately make the function safer and more predictable.

This change would:

• Clarify the function’s behavior by strictly enforcing input boundaries,
• Align with user expectations that the specified seed is actually used,
• Reduce the risk of subtle, hard-to-trace bugs (especially in distributed settings where logs are noisy).

While a few workflows might rely on the current behavior, I believe it’s more important to alert users to invalid input up front rather than defaulting to 0.

Explicit errors are preferable to silent failures, especially for issues concerning reproducibility. Happy to discuss further!

[deependujha]

Sure.
Can you make a PR and let's see if we can get this landed.

[jonathanking]

Thanks, in my proposed PR, I only updated the behavior when the user specifies the seed during the function call, but not if they specify it as a global variable. Please let me know if you have thoughts or concerns.