[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: FYI, I've updated Cython's module import checks to include an interpreter check. This (multi-file) test shows the new behaviour, which is to raise an ImportError on module creation when it detects a different interpreter than during the initial import:

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: Well, first of all, it's better than a crash. :) Secondly, I'm sure NumPy doesn't currently support subinterpreters, just like most other extension modules. If I'm not mistaken, an interpreter switch can be detected through the interpreter state pointer [1]

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Petr Viktorin added the comment: That's quite problematic, since then you're sharing a mutable object across interpreters. The user can store any attribute on module objects, including e.g. Python functions that reference their original interpreter's global state, but become callable in

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: I think the best work-around for now is to implement a bit of PEP 489, including a module create function that always returns the same static module reference instead of creating a new one after the first call, and a module exec function that simply returns

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Thomas Wouters added the comment: Re: Petr: we can't expect extension module authors to retroactively fix released modules. We can't even expect everyone to fix this for future releases; moving away from globals (which may not be specific to the Python extension module)

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Stefan Behnel added the comment: > change the extension module cache to key on filename and init function name ... or on the pointer to the PyInit function. If that's the same, we obviously have the same extension module. If it differs, even for the same module name,

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Change by Stefan Behnel : -- components: +Extension Modules nosy: +scoder ___ Python tracker ___

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Petr Viktorin added the comment: Well, PEP 489 basically punts this to module authors: generally, C globals are bad, but if you do have global state, please manage it, keeping in mind that multiple module objects can be created from the extension. That's required to make

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Eric Snow added the comment: PEP 489 ("Multi-phase extension module initialization") is relevant here, so I've nosied Petr. -- nosy: +encukou ___ Python tracker

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Change by Gregory P. Smith : -- versions: +Python 3.6, Python 3.7, Python 3.8 ___ Python tracker ___

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

New submission from Thomas Wouters : This is a continuation, of sorts, of issue16421; adding most of that issue's audience to the noisy list. When importing the same extension module under multiple names that share the same basename, Python 3 will call the extension