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

[David Mertz]

Sounds good to me!
On Sep 15, 2015 1:19 PM, "Guido van Rossum" <guido at python.org> wrote:

> How about the following. We add a fast secure random generator to the
> stdlib as an option, and when it has proven its worth a few releases from
> now we consider again whether the default random() can be made secure
> without breaking anything.
>
> On Tue, Sep 15, 2015 at 12:43 PM, David Mertz <mertz at gnosis.cx> wrote:
>
>> 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/
>>
>>
>> _______________________________________________
>> 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/
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150915/fd93211a/attachment.html>