-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify what to override when subclassing random.Random #131244
Comments
See also #84526. |
The docs are correct. It is the implementation that is buggy. The intent and promise was to make This was true (and likely relied upon) until |
Okay, so |
That is the issue that Victor referenced above and it is also a problem. The inherited I suspect (but don't actually know) this rarely arises in practice. Subclassing isn't common (most people use MT19937 right out of the box). When they do subclass, they tend to add |
@tim-one What do think about automatically adding def _getrandbits_based_on_random(self, n):
result = 0
bits = 0
while n > bits:
result = (result << 53) | _floor(self.random() * 2.0**53)
bits += 53
return result >> (bits - n) This could be added by |
Documentation
In current documentation about the
random.Random
class, it said that overridinggetrandbits()
is optional, so it may make people think just overridingrandom()
is sufficient to control the behavior of the class. But in practice methods likerandbytes
usegetrandbits
, which is implemented in C to get randomness from MT19937. So it has the following behavior:Which shows that overriding
random()
only is not sufficient. From the issue #84466, this seems to be the expected behavior (or not?). So I think this should be documented that overridinggetrandbits()
is not optional.The text was updated successfully, but these errors were encountered: