[issue40601] [C API] Hide static types from the limited C API

Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40601] [C API] Hide static types from the limited C API

Change by h-vetinari : -- nosy: +h-vetinari ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40601] [C API] Hide static types from the limited C API

Guido van Rossum added the comment: FWIW I have an idea that would allow code using e.g. _Type to continue to work, and even ABI compatible (though only in the main interpreter). // In some header file PyAPI_FUNC(PyHeapTypeObject *) PyList_GetType(); #define PyList_Type

[issue40601] [C API] Hide static types from the limited C API

STINNER Victor added the comment: I plan to write such PEP soon. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40601] [C API] Hide static types from the limited C API

STINNER Victor added the comment: The Steering Council asked for a PEP to explain why static types should be converted to heap types. -- ___ Python tracker ___

[issue40601] [C API] Hide static types from the limited C API

junyixie added the comment: It seems that there is no continued progress for move static type in heap.This will make it impossible to continue to achieve sub interpreters parallel. Are there any plans to try other solutions to the problem? In my project, i try to slove this problem, It can

[issue40601] [C API] Hide static types from the limited C API

Petr Viktorin added the comment: Sorry, I lost this bug in my TODO list :( > > I don't think it's necessary here. > > Did you read my rationale (first message)? Do you mean that per-interpreter > GIL is not worth it? Right, I mean that it it is not worth breaking the C-API for all existing

[issue40601] [C API] Hide static types from the limited C API

Change by STINNER Victor : -- keywords: +patch pull_requests: +23227 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24146 ___ Python tracker ___

[issue40601] [C API] Hide static types from the limited C API

STINNER Victor added the comment: PC/python3dll.c exports 66 types in the stable ABI: Py_GenericAliasType PyObject_Type _PyWeakref_CallableProxyType _PyWeakref_ProxyType _PyWeakref_RefType PyBaseObject_Type PyBool_Type PyByteArray_Type PyByteArrayIter_Type PyBytes_Type PyBytesIter_Type

[issue40601] [C API] Hide static types from the limited C API

STINNER Victor added the comment: > Technically, it is not, see > https://www.python.org/dev/peps/pep-0384/#structures > Structures like PyLong_Type are *not* part of the limited API. The symbol is exported by libpython: $ objdump -T /lib64/libpython3.8.so.1.0|grep PyLong_Type

[issue40601] [C API] Hide static types from the limited C API

Change by STINNER Victor : -- components: +Subinterpreters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40601] [C API] Hide static types from the limited C API

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40601] [C API] Hide static types from the limited C API

Petr Viktorin added the comment: > For example, Objects/longobject.c defines "PyTypeObject PyLong_Type = > {...};". This type is exposed in the limited C API (!) Technically, it is not, see https://www.python.org/dev/peps/pep-0384/#structures Structures like PyLong_Type are *not* part of the

[issue40601] [C API] Hide static types from the limited C API

STINNER Victor added the comment: > I propose to break the limited C API backward compatibility on purpose by > removing these type definitions form the limited C API. Hum. How would a C extension subclass the Python int type (PyLong_Type) if it's no longer exposed? One option is to add one

[issue40601] [C API] Hide static types from the limited C API

STINNER Victor added the comment: See also bpo-40077: "Convert static types to PyType_FromSpec()". -- ___ Python tracker ___ ___

[issue40601] [C API] Hide static types from the limited C API

New submission from STINNER Victor : "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