I dislike the “block” term for a different reason: it suggests raising EAGAIN (= BlockingIOError). But the proposal here is actually to generate data with low entropy.

In the long term, it sounds like two separate functions is the way to go. I would prefer os.urandom() to retain its 3.5.1 behaviour introduced by Issue 22181: wait for sufficient entropy. This would be consistent with other platforms. It can continue to be used by SystemRandom, secrets, etc. The documentation should be clarified to say that os.urandom() either returns data that is supposed to be “unpredictable enough for cryptographic applications”, blocks waiting for entropy, or raises an NotImplementedError if an OS API (e.g. /dev/urandom) is missing.

The other function, say os.urandom_even_with_low_entropy(), would work like the old os.urandom() on Linux. On platforms like Free BSD, I guess it could fall back to the os.urandom() that waits for entropy. “Import random” would be changed to try this function.

I wonder what we should do on Linux if /dev/urandom is unavailable and getrandom() would block. Probably raise NotImplementedError without waiting for entropy.