I'm not an expert in CPython's internals either, but import lock does not need to equal global interpreter lock. I do agree though, that this behavior isn't intuitive at all.

GIL stands for both Global Interpreter Lock and Global Import Lock.

Yeah, obviously two totally different things. Just a cheeky title since I found it humorous that they both ended up with the same acronyms and the GIL at this point is well understood/feared/discussed while this import lock is something that I hadn't ever heard of.

So why can't importing a module block until the import lock can be acquired, rather than throwing an exception?

I don't completely understand that either. This comment from the ticket that originated the behavior ( http://bugs.python.org/issue1567 ) comes with the following explanation:

  It fixes several issues related to dead locks when a thread uses a
  function that imports a module but another thread holds the lock. It
  doesn't require static caching of modules.

The idea that deadlocks were a problem makes me think that this import lock isn't exactly 'global', per-se.

The thing about Python is that it is a scripting language. Importing a Python module involves executing arbitrary code.

Here is a quick rundown of how a deadlock can occur:

1. The main module runs in Thread #1, which imports module "foo".

2. Module "foo" has code at the top level that starts a new thread (Thread #2), and then blocks waiting for it to do something.

3. In Thread #2, someone calls datetime.strptime(). This deadlocks because now Thread #2 needs to import "_strptime" but Thread #1 holds the Global Import Lock because it is importing "foo".

This is exactly the use case for Recursive Mutexes.

I don't think so. It sounds like this is about one thread trying to acquire the lock while another holds it, not the same thread trying to acquire the same lock twice.