[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: FYI, I'm going to focus discussion on the capi-sig thread. -- ___ Python tracker ___ ___

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: > PEP 489 is *very much* part of the limited API. Gah, I missed that. That said, I don't think it matters; I just lose an easy point in the rationale. :) -- ___ Python tracker

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: > I am confused. How can widening the usable number of functions (i.e. using > the whole C-API rather than the limited API) help c-extension modules be > usable in subinterpreters? Aren't the same singletons, exception types, and > other types exposed in the full

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

STINNER Victor added the comment: 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 "_Type" would be excluded. To be clear, the

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Petr Viktorin added the comment: There seems to be much confusion here. Maybe on my side? PEP 489 is *very much* part of the limited API. -- nosy: +petr.viktorin ___ Python tracker

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

mattip added the comment: I am confused. How can widening the usable number of functions (i.e. using the whole C-API rather than the limited API) help c-extension modules be usable in subinterpreters? Aren't the same singletons, exception types, and other types exposed in the full C-API?

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: FYI, I posted to capi-sig about this: https://mail.python.org/archives/list/capi-...@python.org/thread/INLCGPMTYFLRTWQL7RB4MUQZ37JAFRAU/ -- ___ Python tracker

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: One simple solution is to explicitly state that the limited API does not support subinterpreters. This is already implied by the fact that the multi-phase init API (PEP 489) requires subinterpreter support but is not part of the limited API. If we establish

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

STINNER Victor added the comment: > I can never remember what "Py_LIMITED_API" stands for. Include/README file is being written, have a look ;-) https://github.com/python/cpython/pull/24884/files -- ___ Python tracker

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

STINNER Victor added the comment: > * 5 singletons This issue is discussed in bpo-39511 "[subinterpreters] Per-interpreter singletons (None, True, False, etc.)". > Since they are part of the limited API, they have a direct effect on the > stable ABI. This issue is discussed in bpo-40601:

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Guido van Rossum added the comment: I can never remember what "Py_LIMITED_API" stands for. If it's not defined, does that mean we have the *unlimited* API? Is that a superset or a subset of the limited API? Regarding 1a *and* 1b, I think it would help to list the specific reasons

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Change by Eric Snow : -- components: +Extension Modules, Interpreter Core, Subinterpreters ___ Python tracker ___ ___

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Change by Eric Snow : -- keywords: +patch pull_requests: +23642 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/24828 ___ Python tracker

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Change by Eric Snow : -- nosy: +Mark.Shannon, nascheme, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: If the stable ABI weren't an issue then we would probably: * deprecate using the objects directly * do something like (2a) in the meantime It may make sense to do that for "#ifndef Py_LIMITED_API", regardless of how we handle the limited API. --

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: Here are some solutions that I've considered: 1. immutable objects a. make the objects truly immutable/const * not trivial, if possible b. make the objects effectively immutable * (see GH-24828) use a really high refcount to make races irrelevant

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

New submission from Eric Snow : In the limited C-API we expose the following static PyObject variables: * 5 singletons * ~70 exception types * ~70 other types Since they are part of the limited API, they have a direct effect on the stable ABI. The problem is that these objects should not be