[Python-ideas] Python's Source of Randomness and the random.py module Redux
Steven D'Aprano
steve at pearwood.info
Fri Sep 11 15:49:48 CEST 2015
On Thu, Sep 10, 2015 at 04:08:09PM +1000, Chris Angelico wrote:
> On Thu, Sep 10, 2015 at 11:50 AM, Andrew Barnert via Python-ideas
> <python-ideas at python.org> wrote:
> > Of course it adds the cost of making the module slower, and also
> > more complex. Maybe a better solution would be to add a
> > random.set_default_instance function that replaced all of the
> > top-level functions with bound methods of the instance (just like
> > what's already done at startup in random.py)? That's simple, and
> > doesn't slow down anything, and it seems like it makes it more clear
> > what you're doing than setting random.inst.
>
> +1. A single function call that replaces all the methods adds a
> minuscule constant to code size, run time, etc, and it's no less
> readable than assignment to a module attribute.
Making monkey-patching the official, recommended way to choose a PRNG is
a risky solution, to put it mildly. That means that at any time, some
other module that is directly or indirectly imported might change the
random number generators you are using without your knowledge. You want
a crypto PRNG, but some module replaces it with MT. Or visa versa.
Technically, it is true that (this being Python) they can do this now,
just by assigning to the random module:
random.random = lambda: 9
but that is clearly abusive, and if you write code to do that, you're
asking for whatever trouble you get. There's no official API to screw
over other callers of the random module behind their back. You're
suggesting that we add one.
> (If anything, it makes
> it more clearly a supported operation
Which is exactly why this is a terrible idea. You're making monkey-
patching not only officially supported, but encouraged. That will not
end well.
--
Steve
More information about the Python-ideas
mailing list