Transferring a comment I previously made on #27250:

One request I'd make in these discussions is that we avoid using the term "block" - it makes people think of the /dev/random behaviour (i.e. blocking intermittently and unhelpfully), rather than the usually-desired "wait for sufficient entropy on system startup" behaviour. (The only documented case where that behaviour clearly *isn't* desired is for people writing startup scripts on Linux that may run before the system entropy pool is initialised, since doing that has been shown to deadlock the system until the systemd script watchdog times out)

I'd also request that we keep in mind that any Linux user always remains free to write the 3-line utility function:

    def read_urandom(num_bytes):
        with open('/dev/urandom', 'rb') as urandom:
            return urandom.read(num_bytes)

If they want to get precisely the Linux /dev/urandom semantics, and not a Python level abstraction that provides the same kinds of assurances offered by other *nix platforms and by the Windows crypto APIs. While "os" originated as a relatively thin wrapper around POSIX APIs, that's far from universally true these days, especially given the introduction of things like implicit Unicode handling, implicit EINTR handling, os.scandir, dir_fd handling, and more.

I'd also *STRONGLY* request that we avoid adding any new APIs in relation to this that mean "Use os.urandom" is no longer the preferred option to obtain cryptographically strong random numbers in Python. Any such APIs can't be used in single source Python 2/3 code, they invalidate existing third party documentation like https://cryptography.io/en/latest/random-numbers/ and they invalidate answers on Q&A sites like http://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python