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 tim.peters
Recipients mark.dickinson, pitrou, rhettinger, serhiy.storchaka, tim.peters, vstinner
Date 2020-04-23.20:54:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1587675250.5.0.0813829860991.issue40346@roundup.psfhosted.org>
In-reply-to
Content
>> 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 that the documentation is wrong and users must
> not subclass random.Random?

I don't know about the docs, but I do know what the goals were whenever I wrote the code ;-)  It _can_ be subclassed - but so can be any class whatsoever.  There was never an intent to make usefully subclass-ing Random easy:  which is precisely what you've discovered and are attempting to improve.

Already said that's fine by me, with caveats.  It's not worth much that I can see, beyond scratching an "elegance" itch that I don't happen to have in this case.  Who subclasses Random in the real world?  Who would want to?  Python wanted to in order to add SystemRandom, and did as little as necessary to do so usefully.  A long time ago, I believe we also supplied a subclass to give results identical to Python's ancient (& long gone) Wichmann-Hill generator.

Those two are the only cases I've heard of (outside of the test suite).

Provided reworking it doesn't break working code or slow things down, I'm +0.
History
Date User Action Args
2020-04-23 20:54:10tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, pitrou, vstinner, serhiy.storchaka
2020-04-23 20:54:10tim.peterssetmessageid: <1587675250.5.0.0813829860991.issue40346@roundup.psfhosted.org>
2020-04-23 20:54:10tim.peterslinkissue40346 messages
2020-04-23 20:54:10tim.peterscreate