
On 2019-09-20 12:29, Nick Coghlan wrote:
On Wed, 18 Sep 2019 at 18:01, Petr Viktorin <encukou@gmail.com> wrote:
On 9/17/19 8:09 AM, Eddie Elizondo wrote:
So the issue is that the import machinery calls PyState_AddModule after the init function returns.
There's a bit more to it. It seems that the fact that PyState_AddModule is called after the init function is an implementation detail of the default import mechanism of CPython.
For instance, builtins.__import__ can be replaced with an alternate import mechanism that does not use PyState_AddModule. Then, calling PyImport_Import twice on a C will execute the init function twice. If this is a C Extension that holds module state then you wouldn't want that init function to be called twice.
Therefore, PyState_AddModule should always be added to a C Extension that initializes module state in the init function. Then, PyState_FindModule should be used to avoid the re-initialization.
My call would rather be to require alternate import mechanisms to call PyState_AddModule. That way, any module that works with CPython would work with the other importers. There are far fewer custom import mechanisms than custom modules.
Right, I think the documentation you've already added is correct on that front (all extension module import implementations should be automatically calling PyState_AddModule), but we should also mention the reasons why a module might want to call it explicitly:
- in order to use PyState_FindModule (directly or indirectly) from within the extension module's own init function
+1
- in order to work around an existing alternate extension module import function that doesn't call it automatically
At least some standard library extension modules do the latter (they call PyState_AddModule as the last thing they do before returning).
I don't think it's useful to point out the latter in the docs. If you're in that situation, you know it already.