A pseudo-randomly selected recent quote:
It would never occur to me to reach for the random module if I want to do cryptography.
It's sad that so many of the opponents of this change make this kind of comment sooner or later. Security is (rarely) about *any* of *us*! Most of *us* don't need it (if we do, our physical or corporate security has already been compromised), most of *us* understand it, a somewhat smaller fraction of *us* behave in habitually secure ways (at the level we practice oral hygiene, say). That doesn't mean that security has to be #1 always and everywhere in designing Python, but I find it pretty distressing that apparently a lot of people either don't understand or don't care about what's at stake in these kinds of decisions *for the rest of the world*. The reality is that security that is not on by default is not secure. Any break in a dike can flood a whole town. The flip side is that security has costs, specifically the compatibility break, and since security needs to be on by default, the aggregate burden should be *presumed large* (even a small burden is spread over many users). Nevertheless, I think that the arguments to justify this change are pretty good: (1) The cost of adapting per program seems small, and seems to restricted to a class of users (software engineers doing regression testing and scientists doing simulations) who probably can easily make the change locally. Nick's proto-PEP is specifically designed so that there will be no cost to naive users (kids writing games etc) who don't need access to state. Caveat: there may be a performance hit for some naive users. That can probably be avoided with an appropriate choice of secure RNG, but that hasn't actually been benchmarked AFAIK. (2) ISTM there are no likely attack vectors due to choice of default RNG in random.random, based on Tim's analysis, but AFAICS he's unwilling to say it's implausible that they exist. (Sorry for the double negative!) I take this to mean that there may be real risk. (3) The anecdotal evidence that the module's current default is frequently misused is strong (the StackOverflow recipes for password generation). Two out of three ain't bad. YMMV, of course.