Home Original page

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

David Mertz mertz at gnosis.cx
Tue Sep 15 21:43:30 CEST 2015 
I commonly use random.some_distribution() as a quick source of "randomness"
knowing full well that it's not cryptographic. Moreover, I usually do so
initially without setting a seed.

The first question I want to answer is "does this random process behave
roughly as I expect?" But in the back of my mind is always the thought,
"If/when I want to reuse this I'll add a seed for reproducibility". It
would never occur to me to reach for the random module if I want to do
cryptography.

It's a good and well established API that currently exists. Sure, add a
submodule random.crypto (or whatever name), but I'm -1 on changing anything
whatsoever on the module functions that are well known.
On Sep 15, 2015 11:26 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?) - so changing it
> isn't likely to affect anyone - anyone needing MT is likely to also be
> using the seed functions.
>
> >   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?
>
> [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.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150915/83a42e0c/attachment.html>
More information about the Python-ideas mailing list