The patch adds a new API method _PyImport_ImportModuleNoLock(const char
*name). It works mostly like PyImport_ImportModule except it does not
block. It tries to fetch the module from sys.modules first and falls
back to PyImport_ImportModule UNLESS the import lock is held by another
thread.

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 patch is against py3k but I can backport it to 2.6.

Doesn't seem to be IDLE related, removed IDLE tag.

Can you produce a version of the patch that applies cleanly to 2.6? Then
we can apply it there first and merge into 3.0 later.

But I wonder.  It seems this changes every single call to
PyImport_ImportModule() in the core to _PyImport_ImportModuleNoLock(). 
What's the point of the lock at that point?

The patch does't replace all PyImport_ImportModule() calls with the new
function. It replaces only the calls which may occure more than once and
have a fixed name like "time".

I've renamed the function to PyImport_ImportModuleNoBlock(). It should
explain the purpose of the function better. It imports a module without
blocking.

I see.  I think there's still something uncomfortable with this function
though -- it looks in sys.modules, but if it doesn't find it there, it
invokes the full-blown import machinery, which calls the (possibly
overridden) __import__ builtin, which in turn might do a relative import
(at least in 2.6) or any amount of funny business.

The only thing that really worries me here is the possibility of
relative import.  I'm thinking that relative import is really never
meant to be when called from C, so perhaps it would be sufficient to
modify the call to __import__ at the end of PyImport_Import() to add a
5th parameter, zero, to always force absolute import.  A quick concept
test shows that this doesn't break anything, though it is worth checking
the docs.

Guido van Rossum wrote:
> The only thing that really worries me here is the possibility of
> relative import.  I'm thinking that relative import is really never
> meant to be when called from C, so perhaps it would be sufficient to
> modify the call to __import__ at the end of PyImport_Import() to add a
> 5th parameter, zero, to always force absolute import.  A quick concept
> test shows that this doesn't break anything, though it is worth checking
> the docs.

Committed in r59678
I've changed PyImport_Import to always use absolute imports as
requested. The docs didn't promise relative imports. It's probably a
mistake to allow relative imports in the first place.

I've also updated the docs and NEWS.