> There are a number of functions in os.py that add additional logic ontop of the system calls, like:

All the functions you name don't have POSIX equivalents, except popen and scandir.

popen provides a lot of functionality around popen (which internally does fork()/exec()).  But fundamentally it behaves like popen, and its behavior is predictable across platforms.

scandir() says right in the documentation: it's implemented using opendir() and readdir().  This makes the behavior predictable across platforms.

You might have also cited os.utime(), which hides byzantine complexity internally and may be implemented with one of about a half-dozen local calls.  But is behavior is predictable across platforms.

/dev/urandom behaves very differently on different platforms, to an extent that CPython can't reasonably be expected to hide the cross-platform behavior and behave in an outwardly predictable manner.  On Linux, by default it should never block, and we could theoretically provide additional functionality to let it block and guarantee high-quality random bits.  On OS X, we don't have any option: it will never block, and it will never provide high-quality random bits.  On FreeBSD, we don't have any option: it could locally block, and if the user would prefer to not block and get lower-quality random numbers as a result, sorry they're out of luck.

It's not reasonable for os.urandom() to hide this complexity.  It is better that os.urandom() is a thin layer around /dev/urandom, and behaves predictably like /dev/urandom on the local computer.  The block= parameter confuses the matter greatly, which is why I oppose it.


> This statement doesn't make any sense to me... you're asserting that because a lot of people are using os.urandom assuming it's going to give them cryptographically secure random numbers... we shouldn't change the implementation of this function to assure that they are going to get cryptographically secure random numbers?

You misunderstand me.  I assert that people are calling os.urandom() because they expect it to behave like /dev/urandom on their machine.  I make no assertion what they expect to happen as a result.  What is returned by os.urandom() is platform-dependent.

If you read the documentation for os.urandom(), it specifically does *not* guarantee the result is suitable for cryptography.  The one-line summary seems to suggest that it does, but then in the very next paragraph it clarifies the situation:

"This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation."

I *am* asserting that /dev/urandom is guaranteed to not block on Linux, therefore os.urandom() should never block on Linux.