> My personal preference would be for os.urandom(n) to favor non-blocking operation over cryptographic security, and either add os.random() or add an optional parameter to os.urandom() to make the opposite trade-off.

Insecure by default is very rarely the right trade off. There are thousands of projects using ``os.urandom()`` already assuming it's going to give them cryptographically strong numbers. If we want a "maybe random" function or option, then it should be the new thing, not the other way around.

I have no problem with SipHash using a possibly insecure random so that Python can start up quickly even in the face of an unitialized urandom on Linux. I do have a problem with infecting every single call to os.urandom with that same choice.

> The current behavior is that Python *will not start at all* if getrandom() blocks (because the hash secret initialization fails).

It starts jsut fine, it just can possible takes awhile.