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.