Interesting. Your example code doesn't run afoul of any of the "don't do this" flags relating to import that I put into the threading docs, so it seems like a fair complaint to me.

As Christian pointed out on c.l.p, the idea with this API is to turn deadlocks triggered due to violations of the first rule noted in http://docs.python.org/library/threading.html#importing-in-threaded-code into exceptions instead. This is *much* friendlier than the old behaviour.

However, as your example shows, there are cases involving the main module where the new approach will throw an exception but a deadlock would not have occurred if it had just waited for the import lock to be released.

Note the difference in behaviour if the invocation style is changed to hold the import lock when the module is executed:

$ ./python -c "import noblock"
acquire
strptime
exit
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

(The bizarre exception noise at the end is due to the violation of rule 2 at the page linked above - since the example code used thread rather than threading, we tried to release an import lock that didn't exist any more. If the code had used threading instead it would have worked fine and printed "released" as expected)

My instinct says that allowing *_NoBlock() to block(!) when invoked from the main Python thread will "do the right thing", but I'm going to want to ponder that for a while. Inadvertently recreating the deadlocks that this whole mechanism is designed to eliminate would be dumb.