homepage

modules_by_index is a near-eternal store for extension modules. It is only collected at the end of interpreter shutdown, which is much too late for regular garbage collection. This patch proposes instead to store weak references in modules_by_index, so that extension modules can be collected in a normal way when they are removed from sys.modules.
The only gotcha is that PyState_FindModule returns a borrowed reference. With this change, it becomes really important to incref the returned reference as soon as possible.

Won't that change to PyState_FindModule() break code? And is it part of the stable ABI?

Theoretically, people *should* already incref the result from PyState_FindModule. On the other hand, the object currently wouldn't be lost unless something else calls PyState_RemoveModule(), which is hardly every used AFAICT.
The only saving grace is that PyState_FindModule() is py3-specific, and only used for extension modules which have a positive m_size (probably not many of them yet).
(I think this issue teaches us that borrowed ref-returning APIs are a bad idea)
Unfortunately, without this change, we also make it difficult or impossible to reclaim extension modules using the GC. At least I cannot think of another way.

Sounds like it needs to be changed with a notice in What's New.

It seems to me that the more appropriate change here would be to redefine PyState_FindModule as return a *new* ref rather than a borrowed ref and have it do the Py_INCREF before returning.
Code using it would then need to add an appropriate Py_DECREF. A reference leak is generally a less dangerous bug than an early free.

> It seems to me that the more appropriate change here would be to
> redefine PyState_FindModule as return a *new* ref rather than a
> borrowed ref and have it do the Py_INCREF before returning.
> 
> Code using it would then need to add an appropriate Py_DECREF. A
> reference leak is generally a less dangerous bug than an early free.
I hadn't thought about that. Code must add Py_DECREF only on 3.4+, then.

(and of course, with module states not being PyObjects, we have the same lifetimes issues as with Py_buffers not being PyObjects....)

I think the "new new module initialization scheme", if it takes steam, is much more promising to solve the underlying issue. I'm inclined to close this entry as "won't fix", what do you think?

Fine by me.

Ok, rejecting my own patch because of compatibility issues.