[Python-ideas] Globally configurable random number generation

[Paul Moore]

On 14 September 2015 at 14:32, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I'll write it up as a full PEP later, but I think it's just as useful
> in this form for now.

Please provide costs and benefits. At the moment, the proposal takes
an implied stance that fixing security issues warrants disruption to
users (and in particular to users with *no* security requirements). I
appreciate that there's the usual 2-release long deprecation process,
and that the only visible disruption is to the state/seed APIs. But
I'd like to see that expanded on a little more, precisely to convince
those people who *aren't* automatically convinced by "there's a
security issue" arguments, that the trade-offs have been properly
analyzed.

For example, in terms of costs:

1. The module API is more complex and harder to teach.
2. The new API deliberately introduces a global state setting API.
3. People using "from random import choice" can't use the "simple
upgrade" recommendation "from random import system_random as random".

The benefits seem to be solely:

1. Users of code written based on bad advice will be protected from
the consequences (as long as the code runs on a sufficiently new
version of Python).

(I'm serious - that's how the benefit statement reads to me. Although
I agree it'd be nice if I worded it a bit more unemotionally, I
genuinely don't know how to without either overstating it or making it
a paragraph long...)

I'm not trying to say that the cost/benefit analysis doesn't justify
the change (I'm currently unconvinced, and trying to remain open in
spite of the over-abundance of security rhetoric in the thread), just
that it's a key point of the debate here, and it's not captured in
your summary/pre-PEP.

Paul