Home Original page

[Python-ideas] PEP 504: Using the system RNG by default

Guido van Rossum guido at python.org
Tue Sep 15 20:36:10 CEST 2015 
On Tue, Sep 15, 2015 at 11:25 AM, Random832 <random832 at fastmail.com> wrote:

> On Tue, Sep 15, 2015, at 13:33, Guido van Rossum wrote:
> > I don’t want to change this API and I don’t want to introduce deprecation
> > warnings – the API is fine, and the warnings will be as ineffective as
> > the
> > warnings in the documentation.
>
> The output of random.random today when it's not seeded / seeded with
> None isn't _really_ deterministic - you can't reproduce it, after all,
> without modifying the code (though in principle you could do
> seed(None)/getstate the first time and then setstate on subsequent
> executions - it may be worth supporting this use case?)


Yes, that's how I would do it (better than using a weak seed).


> - so changing it
> isn't likely to affect anyone - anyone needing MT is likely to also be
> using the seed functions.
>

Or they could just make a lot of random() calls and find their performance
down the drain (like what happened in the tracker issue that started all
this: http://bugs.python.org/issue25003).


> >   random.set_random_generator(<instance>)
>
> What do you think of having calls to seed/setstate(/getstate?)
> implicitly switch (by whatever mechanism) to MT? This could be done
> without a deprecation warning, and would allow existing code that relies
> on reproducible values to continue working without modification?
>

I happen to believe that MT's performance is a feature of the (default)
API, and this would still be considered breakage (again, as in that issue).

[indirection in global functions]...
> > (and similar for all related functions).
>
> global getstate/setstate should also save/replace the _inst or its type;
> at least if it's a different type than it was at the time the state was
> saved. For backwards compatibility in case these are pickled it could
> use the existing format when _inst is the current MT implementation, and
> accept these in setstate.
>
> > It would also be fine for SystemRandom (or
> > at
> > least whatever is used by use_secure_random(), if SystemRandom cannot
> > change for backward compatibility reasons) to raise an exception when
> > seed(), setstate() or getstate() are called.
>
> SystemRandom already raises an exception when getstate and setstate are
> called.
>

Great!

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150915/fa4eb2fb/attachment-0001.html>
More information about the Python-ideas mailing list