You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BUG: SeedSequence accepts types outside of spec #27380
SeedSequence supports None, int, Sequence[int] for entropy. It turns out that anythign with len(obj)==0 in the leading dimension will be accepted and is identical to 0. This includes ndarrays with any number of dimensions.
This might be more of a FR than a bug, but the lack of standardization could increase end users error risk.
The 0-padding behavior for [] should certainly be documented (we 0-pad out to pool_sizeuint32 integers so that spawning doesn't create conflicts).
We certainly could tighten up our validation in _coerce_to_uint32_array(). What we implemented there was really an older proposal that didn't make the final cut that allowed a lot more than what we currently document because we thought we might want to allow things like hex-int '0x1badcafe' strings for ease of integration. That could certainly use another pass to align it with the final documentation.
As a rule though, the documentation defines the standard and things outside of what's documented MAY raise a helpful exception but MAY also just execute with undefined behavior. Possibly worth tightening up if it's easy, but not urgently.
Activity
rkern commentedon Sep 12, 2024
The 0-padding behavior for
[]should certainly be documented (we 0-pad out topool_sizeuint32integers so that spawning doesn't create conflicts).We certainly could tighten up our validation in
_coerce_to_uint32_array(). What we implemented there was really an older proposal that didn't make the final cut that allowed a lot more than what we currently document because we thought we might want to allow things like hex-int'0x1badcafe'strings for ease of integration. That could certainly use another pass to align it with the final documentation.As a rule though, the documentation defines the standard and things outside of what's documented MAY raise a helpful exception but MAY also just execute with undefined behavior. Possibly worth tightening up if it's easy, but not urgently.