Just to re-state; I think we have three problems:

1) _Py_HashSecret initialization blocking. Affects all Python invocations; already a substantial issue on Debian testing track (90s startup delay).

* there seems to be general agreement that this does not need a 'strong' secret in a script called at/near startup.
* On Linux, getrandom(GRND_NONBLOCK) *or* /dev/urandom are sufficient for this initialization.
* On other OS, we don't have a non-blocking kernel PRNG; this is probably not an issue for Solaris or OS X, and only a possible issue for OpenBSD.
* Is it acceptable to fall back to an in-process seed generation for the cases where initialization via /dev/urandom fails (NB : there have been no reports of this type of failure in the wild).

* existing tip with or without nonblocking_urandom_noraise.patch addresses this for Linux. Solution for other OS remains to be written.
* Possibly can be considered non-blocking for other OS, as there has been no recent regression in behavior.

2) Blocking on 'import random' and/or os.urandom. I don't see a clear consensus on the Right Thing for this case. Existing tip (without nonblocking_urandom_noraise.patch) addresses it for Linux, but solution is not universally accepted. Unclear whether this is a 3.5.2 blocker.

3) Design of future APIs for >= 3.6. The most frequent suggestion is something like os.pseudorandom() (guaranteed nonblocking) and os.cryptorandom() (guaranteed entropy); I guess this needs to go to the dev list for full discussion - is it safely out of scope for this bug?

My suggestion (for what it's worth): accept Victor's changeset plus nonblocking_urandom_noraise for 3.5.2 (I'll submit a proper patch shortly), recommend userspace workarounds for the blocking urandom issue, propose new APIs for 3.6 on the dev list.