Yep. See http://bugs.python.org/issue10915 and http://bugs.python.org/issue15751. The issue of C-extension support for subinterpreters is, of course, a critical one here. At the very least, incompatible modules should be able to opt out of subinterpreter support. I've updated the PEP to discuss this.
-eric On Sun, Sep 10, 2017 at 3:18 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote: > >> On 8 Sep 2017, at 05:11, Eric Snow <ericsnowcurren...@gmail.com> wrote: > >> On Thu, Sep 7, 2017 at 3:48 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >>> Numpy is the one I'm >>> most familiar with: when we get subinterpreter bugs we close them >>> wontfix, because supporting subinterpreters properly would require >>> non-trivial auditing, add overhead for non-subinterpreter use cases, >>> and benefit a tiny tiny fraction of our users. >> >> The main problem of which I'm aware is C globals in libraries and >> extension modules. PEPs 489 and 3121 are meant to help but I know >> that there is at least one major situation which is still a blocker >> for multi-interpreter-safe module state. Other than C globals, is >> there some other issue? > > There’s also the PyGilState_* API that doesn't support multiple interpreters. > > The issue there is that callbacks from external libraries back into python > need to use the correct subinterpreter. > > Ronald _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
