[Guido]
>> ...
>> Tim's proposal is simple: create a new module, e.g. safefandom, with the
>> same API as random (less seed/state). That's it. Then it's a simple import
>> change away to do the right thing, and we have years to seed StackOverflow
>> with better information before that code even hits the road. (But a backport
>> to Python 2.7 could be on PyPI tomorrow!)
[Nick Coghlan <ncoghlan@gmail.com>]
> If folks are reaching for a third party library anyway, we'd be better
> off point them at one of the higher levels ones like passlib or
> cryptography.
Note that, in context, "saferandom" _would_ be a standard module in a
future Python 3 feature release. But it _could_ be used literally
tomorrow by anyone who wanted a head start, whether in a current
Python 2 or Python 3.
+1 on the overall idea, although I would rather the module be named random.safe in the stdlib ("namespaces are one honking great idea" and it helps keep the "safer" version of random near the "unsafe" version in the module index which makes discovery easier). And as long as the version on PyPI stays Python 2/3 compatible people can just rely on the saferandom name until they drop Python 2 support and then just update their imports.
And if pieces of `passlib` and/or `cryptography` are thought to be
essential for best practice, cool, then `saferandom` could also become
a natural home for workalikes. Would you really want to _ever_ put
such functions in the catch-all "random" module? The docs would
become an incomprehensible mess.
So, a PEP for this to propose which random algorithm to use (I have at least heard chacha/ch4random and some AES thing bandied about as being fast)? And if yes to a PEP, who's writing it? And then who is writing the implementation in the end?