<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 15, 2015 at 8:40 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.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 16 September 2015 at 03:33, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> I had to check out of the mega-threads, but I really don't like the outcome<br>
> (unless this PEP is just the first of several competing proposals).<br>
><br>
> The random module provides a useful interface – a random() function and a<br>
> large variety of derived functionality useful for statistics programming<br>
> (e.g. uniform(), choice(), bivariate(), etc.). Many of these have<br>
> significant mathematical finesse in their implementation. They are all<br>
> accessing shared state that is kept in a global variable in the module, and<br>
> that is a desirable feature (nobody wants to have to pass an extra variable<br>
> just so you can share the state of the random number generator with some<br>
> other code).<br>
><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 the<br>
> warnings in the documentation.<br>
<br>
</span>The proposed runtime warnings are just an additional harder to avoid<br>
nudge for folks that don't read the documentation, so I'd be OK with<br>
dropping them from the proposal.</blockquote><div><br></div><div>Good, because I really don't want the warnings, nor the hack based on whether you call any of the seed/state-related methods.<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">However, it also occurs to me there<br>
may be a better solution to eliminating them than getting people to<br>
change their imports: add a "random.ensure_seedable()" API that flips<br>
the default instance to the deterministic RNG without triggering the<br>
warning.<br>
<br>
For applications that genuinely want the determinism, warnings free<br>
3.6+ compatibility would then look like:<br>
<br>
    if hasattr(random, "ensure_seedable"):<br>
        random.ensure_seedable()<span class=""><br></span></blockquote><div><br></div><div>I don't believe that seedability is the only thing that matters. MT is also over an order of magnitude faster than os.urandom() or SystemRandom.<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"><span class="">
> I am fine with adding more secure ways of generating random numbers. But we<br>
> already have random.SystemRandom(), so there doesn’t seem to be a hurry?<br>
><br>
> How about we make one small change instead: a way to change the default<br>
> instance used by the top-level functions in the random module. Say,<br>
><br>
>   random.set_random_generator(<instance>)<br>
<br>
</span>That was my previous proposal. The problem with it is that it's much<br>
harder to test and support, as you have to allow for the global<br>
instance changing multiple times, and in multiple different<br>
directions.<br></blockquote><div><br></div><div>Actually part of my proposal was a use_secure_random() that was also a one-way flag flip, just in the opposite direction. :-)<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">
With the proposal in the PEP, there's only a single idempotent change<br>
that's possible: from the system RNG (used by default to eliminate the<br>
silent security failure) to the seedable RNG (needed for<br>
reproducibility).<br></blockquote></div><br></div><div class="gmail_extra">I'd be much more comfortable if in 3.6 we only introduced a new way to generate secure random numbers that was as fast as MT. Once that has been in use for a few releases we may have a discussion about whether it's time to make it the default.<br><br></div><div class="gmail_extra">Security isn't served well by panicky over-reaction.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>