New submission from STINNER Victor <[email protected]>:
"Statically allocated types" prevents to get per-interpreter GIL: bpo-40512.
These types are currently shared by all interpreters.
Eric Snow proposed the idea of creating a heap allocated type in
subintepreters. But we should take care of direct usage of the statically
allocated type.
For example, Objects/longobject.c defines "PyTypeObject PyLong_Type = {...};".
This type is exposed in the limited C API (!) in Include/longobject.c:
PyAPI_DATA(PyTypeObject) PyLong_Type;
It's used but such macro:
#define PyLong_CheckExact(op) Py_IS_TYPE(op, &PyLong_Type)
I don't think that these types are directly accessed in C extensions built with
the limited C API. My expectation is that the type is only exposed for
"CheckExact" macros.
Currently, 100 statically allocated types are declared in Python header files:
$ grep -F '(PyTypeObject)' Include/ -R
Include/cpython/fileobject.h:PyAPI_DATA(PyTypeObject) PyStdPrinter_Type;
(...)
Include/object.h:PyAPI_DATA(PyTypeObject) PySuper_Type; /* built-in 'super' */
Include/methodobject.h:PyAPI_DATA(PyTypeObject) PyCFunction_Type;
Most of them seem to be exposed in the limited C API.
I propose to break the limited C API backward compatibility on purpose by
removing these type definitions form the limited C API.
For "CheckExact" macros, we can continue to provide them in the limited C API
but as function calls. So a built C extension would no longer access directly
the type, but only do function calls.
----------
components: C API
messages: 368667
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Hide static types from the limited C API
versions: Python 3.9
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue40601>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
