<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 15, 2015 at 11:25 AM, Random832 <span dir="ltr"><<a href="mailto:random832@fastmail.com" target="_blank">random832@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">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>
</span>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?)</blockquote><div><br></div><div>Yes, that's how I would do it (better than using a weak seed).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - so changing it<br>
isn't likely to affect anyone - anyone needing MT is likely to also be<br>
using the seed functions.<br></blockquote><div><br></div><div>Or they could just make a lot of random() calls and find their performance down the drain (like what happened in the tracker issue that started all this: <a href="http://bugs.python.org/issue25003">http://bugs.python.org/issue25003</a>).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>   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></blockquote><div><br></div><div>I happen to believe that MT's performance is a feature of the (default) API, and  this would still be considered breakage (again, as in that issue).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[indirection in global functions]...<br>
<span class="">> (and similar for all related functions).<br>
<br>
</span>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>
<span class=""><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>
</span>SystemRandom already raises an exception when getstate and setstate are<br>
called.<br></blockquote></div><br></div><div class="gmail_extra">Great!<br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>