This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Mark.Shannon, eric.snow, gvanrossum, mattip, nascheme, petr.viktorin, vstinner
Date 2021-03-17.14:14:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615990499.85.0.465494490529.issue43503@roundup.psfhosted.org>
In-reply-to
Content
Eric Snow proposes that C extensions which want to be compatible with subinterpreters must use an hypothetical variant of the C API which doesn't inherit flaws of the current C API. For example, static types like "&PyLong_Type" would be excluded.

To be clear, the limited C API does expose (indirectly) "&PyLong_Type". We are talking about a new variant of the C API.

The main interpreter would continue to use its static type "&PyLong_Type", whereas each subinterpreter would get its own "int" type allocated on the heap (heap type).

Someone has to write a PoC to ensure that this idea works in practice.

In bpo-40601, I proposed that all interpreters including the main interpreter only use heap types: remove "&PyLong_Type" from the C API which is a backward incompatible C API change.
History
Date User Action Args
2021-03-17 14:14:59vstinnersetrecipients: + vstinner, gvanrossum, nascheme, petr.viktorin, Mark.Shannon, eric.snow, mattip
2021-03-17 14:14:59vstinnersetmessageid: <1615990499.85.0.465494490529.issue43503@roundup.psfhosted.org>
2021-03-17 14:14:59vstinnerlinkissue43503 messages
2021-03-17 14:14:59vstinnercreate