> IMHO you should read http://www.2uo.de/myths-about-urandom/ which explains that the property of blocking or not blocking doesn't matter for the quality of the RNG. /dev/urandom is good enough to generate crytographic keys. Can we please stay focused on the *uninitialized entropy pool* case?

Cory wasn't speaking about (non)blocking in general, but the case where (apparently) it's desired to not block even if that means you don't get cryptographically secure random in the CPython interpreter start up. Nobody here wants ``os.urandom`` to behave like ``/dev/random`` does on Linux. We just want ``os.urandom`` to always return cryptographically safe random numbers.

> IMHO you are expecting too much from os.urandom(). *If* you consider that secrets require an initialized entropy pool, IMHO you should help Stephan to implement a function to retrieve the implementation of os.urandom() and then take a decision *in the secrets module*. For example, raise an exception. It's the best way to warn users that something goes wrong. I don't think that *blocking* is a good choice.

I think this is a pretty crappy way of handling it-- blocking for a short amount of time is almost always going to be the right thing for people here, particularly since it only matters right at the start of a fresh VM and no other time. I think that it's wrong to let an edge case of PYTHONHASHSEED reduce the security and the ability to reason about the return value of os.urandom for basically every other application of it.