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@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@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/