[Python-ideas] Globally configurable random number generation

[Nick Coghlan]

On 15 September 2015 at 14:03, Andrew Barnert <abarnert at yahoo.com> wrote:
> Also, while I'm not 100% sold on the auto-switching and the delegate-at-call-time wrappers, I'll play with them and see, and if they do work, then you're definitely right that your second version does solve your problem with my proposal, so it doesn't matter whether your first version did anymore.
>
> First, on delegating top-level function: have you tested the performance? Is MT so slow that an extra lookup and function call don't matter?

If folks are in a situation where the performance impact of the
additional layer of indirection is a problem, they can switch to using
random.Random explicitly, or import from random.seedable rather than
the top level random module.

> One quick thought on auto-switching vs. explicitly setting the instance before any functions have been called: if I get you to install a plugin that calls random.seed(), I've now changed your app to use seeded random numbers. And it might even still pass security tests, because it doesn't switch until someone hits some API that activates the plugin. Is that a realistic danger for any realistic apps? If so, doesn't that potentially make 3.6 more dangerous than 3.5?

This isn't an applicable concern, as we already provide zero runtime
protections against hostile monkeypatching of other modules (by design
choice). You can subvert even os.urandom in a hostile plugin:

    def not_random(num_bytes):
        return b'A' * num_bytes
    import os
    os.urandom = not_random

Once "potentially hostile code running in the current process" is part
of your threat model, CPython is out of the running, and even PyPy's
sandboxing capabilities rely on running the potentially hostile code
in a separate process. IronPython and Jython can rely on CLR/JVM
sandboxing, but that's still a case of delegating the problem to the
host platform, rather than trying to solve it at the Python level.

> For another: I still think we should be getting people to explicitly use seeded_random or system_random (or seedless_random, if they need speed as well as "probably secure") or explicit class instances (which are a bigger change, but more backward compatible once you've made it) as often as possible, even if random does eventually turn into seedless_random. The fact that many apps will never actually issue a deprecation warning or any other signal that anything is changing may be leaning over too far toward convenience. I realize the benefit of having books and course materials written for 3.4 continue to work in 3.8, but really, if those books are giving people bad ideas, removing any incentive for anyone to change the next edition may not be a good idea.

Forcing people to make choices they're ill-equipped to make just
because we think they "should" know enough to make a wise decision is
one of the leading causes of user hostile software (consider the
respective user experiences of a HTTP site and a HTTPS site with a
self-signed certificate).

People are busy, and life is full of decisions that need to be made
where there's no good default, so when we're able to deliver a good
default that fails *noisily* when it's the wrong answer, that's what
we should be aiming for.

> And finally: it _seems like_ people who want MT for simulation/game/science stuff will have a pretty easy time finding the migration path, but I'm having a really hard time coming up with a convincing argument. Does anyone have a handful of science guys they can hack up a system for and test them empirically? Because if you can establish that fact, I think the naysayers have very little reason left to say nay, and a consensus would surely be better than having that horribly contentious thread end with "too bad, overruled, the PEP has been accepted".

Given the general lack of investment in sustaining engineering for
scientific software, I think the naysayers are right on that front,
which is why I switched my proposal to give them a transparent upgrade
path - I was originally thinking primarily of the educational and
gaming use cases, and hadn't considered randomised simulations in the
scientific realm.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia