[issue40346] Add random.BaseRandom to ease implementation of subclasses

Serhiy Storchaka added the comment: That you need to override the __new__ method? I don't know whether it is documented specially. But the constructor calls __new__() and then __init__(). If changing the argument in __init__ does not help, it is because it was already proceeded in __new__.

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Matt Bogosian added the comment: Thanks! Where's that documented? (Apologies if I missed it.) -- ___ Python tracker ___ ___

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Serhiy Storchaka added the comment: Matt, your example works in 3.11. In earlier versions you need to override the __new__ method. -- ___ Python tracker ___

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Matt Bogosian added the comment: I landed here after investigating this surprising result: # test_case.py from random import Random from typing import Sequence, Union _RandSeed = Union[None, int, Sequence[int]] class MyRandom(Random): def __init__( self, seed:

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: I created this issue to propose PR 19631 (BaseRandom class) which looked like as a good idea to me: simple base class which fix different kind of problems. But it seems like other people would prefer a complete rewrite from scratch and require a PEP. I

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Raymond Hettinger added the comment: SystemRandom is a weird special case. Otherwise, almost every PRNG is going to need seed(), getstate(), and setstate(). A base class should each offer some reusable code to minimize the burden on the subclass: * The existing seed method allows multiple

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Tim Peters added the comment: To be serious about numpy ;-) , people consuming a great many random outputs will eventually move to numpy out of necessity (speed). So for that reason alone it's good to mimic what they do. But more fundamentally, they have more people with relevant deep

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: Fun fact. When I wrote my "class NumpyRandom(random.BaseRandom):" example, I found a quite serious bug in numpy: "default_rng.integers(2**32) always return 0" https://github.com/numpy/numpy/issues/16066 Even numpy is not perfect yet :-) --

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Mark Dickinson added the comment: [Tim] > Mark, you don't count ;-) Yes, I was suspecting I'd fail the "real world" test. Fair enough. :-) -- ___ Python tracker ___

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Tim Peters added the comment: Mark, you don't count ;-) Neither do I. Of course I've subclassed Random too, to experiment with other base generators (including PCG variants). But they're throwaways, and I don't care that it can require staring at the code to make as many changes as

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: I see 3 options to fix randbytes() in subclasses: (A) Remove the randbytes() optimization (C implementation): always implement it with getrandbits(). (B) Add BaseRandom base class: PR 19631. (C) Modify __init_subclass__() to implement randbytes() with

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Mark Dickinson added the comment: [Victor] > Honestly, if you consider that BaseRandom base class is not worth it, I will > just abandon this idea. It's not that I think it's not worth it (I'm not currently convinced either way). It's more that if we're going to make a change, then it's

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: Raymond Hettinger: "It is not okay to flat out ignore the opposing comments from the module maintainers. Being on the steering committee isn't a license to do whatever you want, ignoring published APIs, breaking user code, and ignoring other contributors.

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: Mark: > With the various competing options and the lack of agreement on what (if > anything) should be done, this feels like PEP territory. Honestly, if you consider that BaseRandom base class is not worth it, I will just abandon this idea. I'm not

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: Antoine: > However, if we want to think about a new subclassing API, it may be worth > looking at the recent Numpy changes. Numpy added a new random generator API > recently, with a design based on composition rather than inheritance (and > also they

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: I created this issue to address Raymond's comment: "The randbytes() method needs to depend on genrandbits()." https://bugs.python.org/issue40286#msg366860 I wrote PR 19700 to address that and only that. With PR 19700, Random subclasses get a randbytes()

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Change by STINNER Victor : -- pull_requests: +19019 pull_request: https://github.com/python/cpython/pull/19700 ___ Python tracker ___

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Mark Dickinson added the comment: > it may be worth looking at the recent Numpy changes Agreed: I do like the NumPy composition model (the random state object _has_ a bit generator, rather than _being_ an extended bit generator). With the various competing options and the lack of agreement

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Mark Dickinson added the comment: Whoops. I thought the URL highlighter would be clever enough not to include the period. That URL is: https://github.com/mdickinson/pcgrandom -- ___ Python tracker

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Mark Dickinson added the comment: [Tim] > Who subclasses Random in the real world? Who would want to? Um. Me? Or at least, I *wanted* to, when I was playing around with PCG. (See https://github.com/mdickinson/pcgrandom.) But after running into the same inelegancies (please note that I'm

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Tim Peters added the comment: >> Making it easy to create subclasses was never a goal regardless. > It's clearly advertised at the beginning of the documentation: > > "Class Random can also be subclassed if you want to use a > different basic generator of your own devising: (...)" > > Do you

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Antoine Pitrou added the comment: If I believe what Victor wrote about: """ The implementation of random.Random, random.SystemRandom and random.Random subclasses are not affected by this change. """ then I don't understand how the API is changed. IIUC, users subclassing random.Random won't

[issue40346] Add random.BaseRandom to ease implementation of subclasses

Raymond Hettinger added the comment: This is a breaking change. The published API says that random() is the base method and that getrandbits() is optional. It is not okay to flat out ignore the opposing comments from the module maintainers. Being on the steering committee isn't a license

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: Ok, PR 19631 is now ready for a review. I completed the documentation to better explain the rationale. Copy of the What's New in Python 3.9 documentation: "Add a new random.BaseRandom class: random number generator base class. A random.BaseRandom subclass

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: In Python 3.8, random.Random docstring starts with "Random number generator base class". I do understand that the random module design predates the abc module (added to Python 2.7). I'm now proposing to add a real base class to move it towards modern

[issue40346] Add random.BaseRandom to ease implementation of subclasses

STINNER Victor added the comment: > Making it easy to create subclasses was never a goal regardless. It's clearly advertised at the beginning of the documentation: "Class Random can also be subclassed if you want to use a different basic generator of your own devising: (...)" Do you mean