Cory Benfield added the comment: > 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
