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

David Mertz mertz at gnosis.cx
Wed Sep 16 06:19:01 CEST 2015

The below said, I confess I never really liked random.random() as a name.
Calling it random.uniform() 20 years ago would have been better. But that's
ancient history, and no big deal.
On Sep 15, 2015 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150915/5b9a0288/attachment-0001.html>

More information about the Python-ideas mailing list