<div dir="ltr"><div>I had to check out of the mega-threads, but I really don't like the
outcome (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 large variety of derived functionality useful for statistics programming (e.g. uniform(), choice(), bivariate(), etc.). Many of these have significant mathematical finesse in their implementation. They are all accessing shared state that is kept in a global variable in the module, and that is a desirable feature (nobody wants to have to pass an extra variable just so you can share the state of the random number generator with some other code).<br><br>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.<br><br>I am fine with adding more secure ways of generating random numbers. But we 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 instance used by the top-level functions in the random module. Say,<br><br> random.set_random_generator(<instance>)<br><br>This would require the global functions to use an extra level of indirection, e.g. instead of<br><br> random = _inst.random<br><br>we’d change that code to say<br><br> def random():<br>     return _inst.random()<br><br>(and similar for all related functions). I am not worried of the cost of the indirection (and if it turns out too expensive we can reimplement the module in C).<br><br>Then we could implement<br><br> def set_random_generator(instance):<br>     global _inst<br>     _inst = instance<br><br></div>We could also have a function random.use_secure_random() that calls set_random_generator() with an instance of a secure random number generator (maybe just SystemRandom()). We could rig things so that once use_secure_random() has been called called, set_random_generator() will throw an exception (to avoid situations where a library module attempts to make the shared random generator insecure in a program that has declared that it wants secure random). 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.<br><br>Of course modules are still free to use their own instances of the Random class. But I don’t see a reason to mess with the existing interface.<br><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></div>