[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Sebastian Krause sebastian at realpath.org
Fri Jun 10 02:39:02 EDT 2016

Nathaniel Smith <njs at pobox.com> wrote:
> (This is based on the assumption that the only time that explicitly
> calling os.urandom is the best option is when one cares about the
> cryptographic strength of the result -- I'm explicitly distinguishing
> here between the hash seeding issue that triggered the original bug
> report and explicit calls to os.urandom.)

I disagree with that assumption. I've often found myself to use
os.urandom for non-secure random data and seen it as the best option
simply because it directly returns the type I wanted: bytes.

The last time I looked the random module didn't have a function to
directly give me bytes, so I would have to wrap it in something like:

bytearray(random.getrandbits(8) for _ in range(size))

Or maybe the function exists, but then it doesn't seem very
discoverable. Ideally I would only want to use the random module for
non-secure and (in 3.6) the secrets module (which could block) for
secure random data and never bother with os.urandom (and knowing how
it behaves). But then those modules should probably get new
functions to directly return bytes.


More information about the Python-Dev mailing list