<p dir="ltr">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.</p>
<div class="gmail_quote">On Sep 15, 2015 12:43 PM, "David Mertz" <<a href="mailto:mertz@gnosis.cx">mertz@gnosis.cx</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<div class="gmail_quote">On Sep 15, 2015 11:26 AM, "Random832" <<a href="mailto:random832@fastmail.com" target="_blank">random832@fastmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 15, 2015, at 13:33, Guido van Rossum wrote:<br>
> I don’t want to change this API and I don’t want to introduce deprecation<br>
> warnings – the API is fine, and the warnings will be as ineffective as<br>
> the<br>
> warnings in the documentation.<br>
<br>
The output of random.random today when it's not seeded / seeded with<br>
None isn't _really_ deterministic - you can't reproduce it, after all,<br>
without modifying the code (though in principle you could do<br>
seed(None)/getstate the first time and then setstate on subsequent<br>
executions - it may be worth supporting this use case?) - so changing it<br>
isn't likely to affect anyone - anyone needing MT is likely to also be<br>
using the seed functions.<br>
<br>
>   random.set_random_generator(<instance>)<br>
<br>
What do you think of having calls to seed/setstate(/getstate?)<br>
implicitly switch (by whatever mechanism) to MT? This could be done<br>
without a deprecation warning, and would allow existing code that relies<br>
on reproducible values to continue working without modification?<br>
<br>
[indirection in global functions]...<br>
> (and similar for all related functions).<br>
<br>
global getstate/setstate should also save/replace the _inst or its type;<br>
at least if it's a different type than it was at the time the state was<br>
saved. For backwards compatibility in case these are pickled it could<br>
use the existing format when _inst is the current MT implementation, and<br>
accept these in setstate.<br>
<br>
> It would also be fine for SystemRandom (or<br>
> at<br>
> least whatever is used by use_secure_random(), if SystemRandom cannot<br>
> change for backward compatibility reasons) to raise an exception when<br>
> seed(), setstate() or getstate() are called.<br>
<br>
SystemRandom already raises an exception when getstate and setstate are<br>
called.<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a></blockquote></div>
</blockquote></div>