Let me make one more thing clear.  I'm willing for os.urandom() to try to use getrandom(GRND_NOBLOCK) (or whatever the flag is called).  This will not block unless the entropy pool is low--which almost never happens.  So 99.9999% of the time, os.urandom() should return lovely high-quality, cryptographically-safe random numbers.

Really this entire debacle is an argument about this funny edge cases, like "you create a new VM and run python3 as PID 0 and your bad sysadmins don't manage the entropy pool and the entropy pool never fills".

What should the code do in that situation?  Is it acceptable to use low-quality bits from /dev/urandom?  Or do they need cryptographically-strong random numbers?  I quote the Zen: "In the face of ambiguity, refuse the temptation to guess."  Thus, we shouldn't block on Linux, and we should behave predictably like /dev/urandom does on the local machine.

This leads me to one reason why I oppose block=.  It's hiding the complexity of the local system with even more complexity, and makes it hard to reason about what the code is doing.  The os module should behave in a predictable manner, as if it was a thin shell around the local system call.  Given that it's impossible to block on Linux and get higher-quality random bits, and it's impossible to *not* block on FreeBSD and get lower-quality random bits, adding block= to os.urandom() means its behavior becomes inobvious and hard to predict.