On Sat, Mar 2, 2019 at 12:33 AM Armin Rigo <[email protected]> wrote:
> PyModule_GetState() requires having the module object that corresponds
> to the given interpreter state.  I'm not sure how a C extension module is
> supposed to get its own module object corresponding to the current
> interpreter state, without getting it from the caller in some way.

Fair enough. :)

> If you want to point out a different approach that might work too, that's OK too.

As Petr noted, the preferred solution isn't feasible yet (pending
several PEPs) and depends on using multi-phase extension module
initialization (PEP 489).  Furthermore, that assumes that the
preferred solution would meet your performance needs.  If you think it
wouldn't then this is a great chance to speak up. :)

> It's just that the current approach was arrived at after multiple generations of
> crash reports, which makes me uneasy about changing it in more subtle ways
> than just killing it in favor of a careful PyInterpreterState_GetDict().

Understood.

Thanks for the detailed explanation on why you are using
"interp->dict", and how you need to avoid fatal errors (e.g. from
"PyImport_GetModuleDict()" during shutdown).

Your solution seems reasonable, since every interpreter will have it's
own "modules" object.  However, note that "interp->modules" can get
swapped out with a different object at any moment.  The use case is
temporarily setting a different import state (e.g. isolating a
module's import).  Currently this isn't very common (especially since
"interp->modules" is currently not sync'ed with "sys.modules"), but we
have plans for making this easier to do from Python code in the
not-distant future.

Regardless, I agree that PyInterpreterState_GetDict() will solve
several problems for you.  I'm sorry we didn't provide this solution
for you sooner.