> What I'm trying to avoid here is the surprising situation where someone is using Python on a system where /dev/urandom will never block, and os.urandom() blocks.

At this point I literally do not understand what issue we're trying to solve then.

If the problem is that os.urandom() must behave exactly like /dev/urandom, then sure, that got regressed.

However, I've been talking based on your two previous pronouncements:

> First, my previous statements stand: Python startup must not block.  "import random" must not block.

and

> I am officially making a pronouncement as Release Manager: Python 3.5 *must
> not* take 90 seconds to start up under *any* circumstances.  I view this as
> a performance regression, and it is and will remain a release blocker for
> 3.5.2.
> 
> Python *must not* require special command-line flags to avoid a 90 second
> startup time.  Python *must not* require a special environment-variable to
> avoid a 90 second startup time.  This is no longer open to debate, and I
> will only be overruled by Guido.

Now, if that's the case, then this patch does not fix that problem. It fixes that problem *on Linux*, but not on BSDs.

Perhaps you meant to say that those pronouncements only apply to Linux. That's fine, it's your prerogative. But as written, they don't: they're unconditional. And if they are unconditional, then again I feel like we have to say that /dev/urandom should get *out* of the call path on interpreter startup, because it absolutely can block. And based on Colm's original problem around gathering entropy, which is almost certainly not a Linux-specific concern, I see no reason to believe that this is a hypothetical concern on the BSDs.

So, let me ask a very direct question: does the position about 90s startup apply only to Linux?