Tim Peters <t...@python.org> 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 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40346> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
