Victor Stinner: I found that comment to be pretty patronising, but I'm assuming that wasn't the intent. However, your characterisation of my comment was not as I intended it: when I said "because it can block", I meant because on almost every system urandom will block if there is insufficient randomness to seed the kernel CSPRNG.

On FreeBSD, /dev/urandom blocks on startup until sufficiently seeded. On OS X, /dev/urandom behaves exactly the same as /dev/random (from the man page: "the two devices behave identically"), which is to say it blocks until the CSPRNG is sufficiently seeded. On Windows, CryptGenRandom (used by this code) specifies no blocking guarantees and the opinion of the wider community is that it too will block until sufficient entropy is gathered from startup.

So, let me say this: if the purpose of this patch was to prevent long startup delays, *it failed*. On all the systems above os.urandom may continue to block system startup. If the purpose of this patch is to prevent the system blocking at startup then you *must not use urandom at Python interpreter startup*.

This is why I object to this patch: it weakens the Linux interpreter while not fixing the actual problem. If Python does not need a CSPRNG at startup, then it should not block waiting for one *on any system*. If it does need a CSPRNG, then it should block until seeded. I don't see why some weird in-between solution is good enough here.