This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients mark.dickinson, pitrou, rhettinger, serhiy.storchaka, tim.peters, vstinner
Date 2020-04-24.17:09:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1587748200.8.0.528066556836.issue40346@roundup.psfhosted.org>
In-reply-to
Content
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 ;-)
History
Date User Action Args
2020-04-24 17:10:00vstinnersetrecipients: + vstinner, tim.peters, rhettinger, mark.dickinson, pitrou, serhiy.storchaka
2020-04-24 17:10:00vstinnersetmessageid: <1587748200.8.0.528066556836.issue40346@roundup.psfhosted.org>
2020-04-24 17:10:00vstinnerlinkissue40346 messages
2020-04-24 17:09:59vstinnercreate