> The block= parameter confuses the matter greatly, which is why I oppose it.

I don't like the block= parameter.

> I assert that people are calling os.urandom() because they expect it to behave like /dev/urandom on their machine.

I don't think most people calling os.urandom have any idea how /dev/urandom behaves on their machine nor do I think most people have any idea how /dev/urandom behaves on other people's machines. In fact, in the original thread there were long time developers stating factually wrong information about the properties of os.urandom. That's not a mark against them, the behavior of random is an esoteric and nuanced thing and there is a lot of misinformation out there about the properties and behavior of it on various systems.


> If you read the documentation for os.urandom(), it specifically does *not* guarantee the result is suitable for cryptography.

Sure, but the cases where os.urandom doesn't provide results suitable for cryptography are:

* Systems where you have a random number generator that is completely broken, in which case there's basically no help for you and you're screwed 10 times over before you even execute Python.
* Linux, in the window prior to the pool being initialized.

That statement is an obvious hedge against the first case, not an allowance for the second case in situations where we don't have to continue to use a worse interface for the same underlying functionality.

If chdir on Linux would, in 0.01% of cases, cause a segfault, but 99.9% of cases work as you'd expect and a new, chdir2 function was added that still changed the directory, but did so in 100% of cases, would you be opposed to changing os.chdir to use chdir2, even though it's no longer a thin wrapper around chdir or would you demand that all developers switch to os.chdir2? Especially if this behavior only really occurred on Linux.