Message 337501 - Python tracker (original) (raw)

On Sat, Mar 2, 2019 at 12:33 AM Armin Rigo <report@bugs.python.org> 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.