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.
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@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/