2016-06-23 2:35 GMT+02:00 Barry Warsaw <barry@python.org>:
Because the os module has traditionally surfaced lower-level operating system functions,
Well, that's not true. os.urandom() is a bad example since it has many implementations depending on the platform. https://haypo-notes.readthedocs.io/pep_random.html#leave-os-urandom-unchange... or https://haypo-notes.readthedocs.io/pep_random.html#operating-system-random-f...
That's also why I advocate simplifying os.urandom() so that it reverts more or less to exposing /dev/urandom to Python. With perhaps a few exceptions, os doesn't provide higher level APIs.
Hum, I modified os.urandom() to use getrandom() to use the private file descriptor and not require the /dev/urandom device. Using a file descriptor has many issues. Tell me if you need more details on these issues. In Python 3.5.2, os.urandom() uses getrandom() on Linux, but only falls back on reading /dev/urandom is getrandom(GRND_NONBLOCK) fails with EAGAIN. I'm not sure that I understand you. Do you want to stop using getrandom()? What about getrandom() on Solaris? And getentropy() on OpenBSD? (And Windows uses CryptGenRandom() ;-))
The point here is that, let's say you're an experienced Linux developer and you know you want to use getrandom(2) in Python. os.getrandom() is exactly that. It's completely analogous to why we provide, e.g. os.chroot() and such.
Even if we modify os.urandom() to make it blocking, adding os.getrandom() makes sense. getrandom() allows also to read /dev/random (not /dev/urandom) without using a FD, getrandom(GRND_NONBLOCK) also gives access to the non-blocking mode. Victor