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

STINNER Victor report at bugs.python.org
Fri Apr 24 13:10:00 EDT 2020


STINNER Victor <vstinner at python.org> 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 getrandbits() in subclasses: PR 19700

--

Option (A) is the simplest, but it makes randbytes() 5x slower.

Option (B) is my favorite: it keeps all random.Random optimization, it reduces SystemRandom footprint by 2 KB, it eases writing new subclasses (a single method must be defined).

Option (C) seems to be complicated to implement. I'm not sure that it does satisfy Raymond's requirements.

--

Option (A) and (C) don't solve my initial concern of this issue: it's not easy to subclass random.Random, it is still required to *override* 5 methods.

The main drawback of option (B) is that Random subclasses now inherit Random.randbytes() and so should override it which is new requirement. But technically, if Random.randbytes() is inherited: it respects its contract, it generates random bytes... it's just that it may not be the behavior expected by the developer.

My PR 19631 solves this drawback by *documenting* the new requirement in the Porting guide of What's New in Python 3.9. I'm not sure if it should be qualified as backward incompatible, but if yes, I propose to make it on purpose (other options have other drawbacks).

--

Honestly, so far, I'm confused. It's now unclear to me if subclassing the random.Random class is a supported feature and/or if we want to support it. It's also unclear to me if the performance matters in the random module. On one side, gauss() has an optimization which makes it not thread-safe, on the other side option (A) would make randbytes() 5x slower.

It's also possible to combine some options like (B)+(C) which solves the main (B) drawback.

Obviously, the last choice is to revert the randbytes() features (decide that it's no longer possible to add such new method to the random.Random because of drawbacks described in this issue).

--

Well, I proposed various options. Now I let you to decide ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40346>
_______________________________________


More information about the Python-bugs-list mailing list