*If* we can guarantee that os.urandom() will never block or raise an exception
when only poor entropy is available, then it may be indeed indistinguishably
backward compatible for most if not all cases.
I stepped through the code that shipped in 3.5.2rc1. It only ever
calls getrandom() with the GRND_NONBLOCK flag. If getrandom()
returns -1 and errno is EAGAIN it falls back to /dev/urandom--I
actually simulated this condition in gdb and watched it open
/dev/urandom. I didn't see any code for raising an exception or
blocking when only poor entropy is available.
As Robert Collins points out, this does change the behavior
ever-so-slightly from 3.4; if urandom is initialized, and the kernel
has the getrandom system call, getrandom() will give us the bytes we
asked for and we won't open and read from /dev/urandom. In this
state os.urandom() behaves ever-so-slightly differently:
os.urandom() will now work in chroot environments where
/dev/urandom doesn't exist.
If Python runs in a chroot environment with a fake
/dev/urandom, we'll ignore that and use the kernel's urandom
device.
If the sysadmin changed what the systemwide /dev/urandom
points to, we'll ignore that and use the kernel's urandom
device.
But os.urandom() is documented as calling getrandom() when available
in 3.5... though doesn't detail how it calls it or what it uses the
result for. Anyway, I feel these differences were minor, and
covered by the documented change in 3.5, so I thought it was
reasonable and un-broken.
If this isn't backwards-compatible enough to suit you, please speak
up now!