Re: [Cython] Should we start using the internal CPython APIs?
Hi All,
>
>> I seriously start wondering if we shouldn't just define
>> "Py_BUILD_CORE"
>
>
> This sounds just too much, and it's like a war declaration on what they
> are trying to do.
>
I have the same opinion. I think this will negate all effort that the C/API
workgroup is trying to do - to limit leaking internals of cpython. I would
do this if there is no other way to move forward.
I would suggest convincing cpython core devs to move API sharing cpython
internals to unstable API tier [1] and to use it. Reasons:
1. This tier is intended for projects like cython ("Tools requiring access
to CPython internals (e.g. advanced debuggers and JIT compilers)" [2])
hence I think there won't be huge opposition to provide needed low-level
API for Cython.
2. Unstable tier has guaranteed stability for each major release so we will
avoid issues with changes in minor releases which can happen for internal
API
Please keep in mind that I am not involved in python API in any way so this
is just my personal opinion with very limited knowledge.
Matus
[1] https://docs.python.org/3/c-api/stable.html#unstable-c-api
[2] https://peps.python.org/pep-0689/#unstable-c-api-tier
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Should we start using the internal CPython APIs?
Thank you for your comments so far. Stefan Behnel schrieb am 29.10.23 um 22:06: I seriously start wondering if we shouldn't just define "Py_BUILD_CORE" (or have our own "CYTHON_USE_CPYTHON_CORE_DETAILS" macro guard that triggers its #define) and include the internal "pycore_*.h" CPython header files from here: https://github.com/python/cpython/tree/main/Include/internal I just remembered that there's a one major technical issue with this. CPython now requires C99 for its own code base (Py3.13 actually uses "-std=c11" on my side). While they care about keeping public header files compatible with C89 and C++, their internal header files may not always have that quality, and won't be tested for it. So, governance is one argument, but technical reasons can also make this appear less appealing overall. I'll let things settle some more and see in what direction Py3.13 will eventually be moving. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
