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.