Home Original page

[Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

Eric Snow ericsnowcurrently at gmail.com
Tue Sep 12 16:48:54 EDT 2017 
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 <ronaldoussoren at mac.com> wrote:
>
>> On 8 Sep 2017, at 05:11, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>
>> On Thu, Sep 7, 2017 at 3:48 PM, Nathaniel Smith <njs at 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
More information about the Python-ideas mailing list