How can we make Python's C-API more friendly for non-C languages?

In my C API strategy draft, there wasn't much opposition to the goal of being “easily usable from non-C languages”. But it's clear that as CPython devs we don't have that much relevant experience with those languages.
I would like to ask developers of Python bindings, FFIs and alternate C-API implementations for thoughts, suggestions, and pain points to help guide the future of the C-API.
I'll collect thoughts in this Google document, though I'm happy to discuss anywhere else: https://docs.google.com/document/d/1fDfF7JanOEyQ9awhKE87-Ajp3H4k7qXL3cmyzPMo...
I've already asked:
- PyPy/cpyext:
https://mail.python.org/archives/list/pypy-dev@python.org/thread/44IO4GHWBEV...
- PyO3 (Rust): https://github.com/PyO3/pyo3/discussions/2346
- nanobind (C++): https://github.com/wjakob/nanobind/discussions/31
If you know more, please let them (or me) know!

On Fri, Apr 29, 2022 at 10:25 AM Petr Viktorin encukou@gmail.com wrote:
In my [C API strategy draft], there wasn't much opposition to the goal of being “easily usable from non-C languages”. But it's clear that as CPython devs we don't have that much relevant experience with those languages.
I would like to ask developers of Python bindings, FFIs and alternate C-API implementations for thoughts, suggestions, and pain points to help guide the future of the C-API.
I'll collect thoughts in this Google document, though I'm happy to discuss anywhere else:
https://docs.google.com/document/d/1fDfF7JanOEyQ9awhKE87-Ajp3H4k7qXL3cmyzPMo...
I've already asked:
- PyPy/cpyext:
https://mail.python.org/archives/list/pypy-dev@python.org/thread/44IO4GHWBEV...
- PyO3 (Rust): https://github.com/PyO3/pyo3/discussions/2346
- nanobind (C++): https://github.com/wjakob/nanobind/discussions/31
If you know more, please let them (or me) know!
pybind11?

On 29.04.2022 19:22, Petr Viktorin wrote:
In my C API strategy draft, there wasn't much opposition to the goal of being “easily usable from non-C languages”. But it's clear that as CPython devs we don't have that much relevant experience with those languages.
I would like to ask developers of Python bindings, FFIs and alternate C-API implementations for thoughts, suggestions, and pain points to help guide the future of the C-API.
I'll collect thoughts in this Google document, though I'm happy to discuss anywhere else: https://docs.google.com/document/d/1fDfF7JanOEyQ9awhKE87-Ajp3H4k7qXL3cmyzPMo...
I've already asked:
- PyPy/cpyext:
https://mail.python.org/archives/list/pypy-dev@python.org/thread/44IO4GHWBEV...
- PyO3 (Rust): https://github.com/PyO3/pyo3/discussions/2346
- nanobind (C++): https://github.com/wjakob/nanobind/discussions/31
If you know more, please let them (or me) know!
Boost.Python (C++): https://www.boost.org/ SIP (C++): https://www.riverbankcomputing.com/software/sip/ Lupa (LUA): https://github.com/scoder/lupa Python.NET (.NET): http://pythonnet.github.io/ JPype (Java): https://github.com/jpype-project/jpype Jep (Java): https://github.com/ninia/jep PyJnius (Java): https://github.com/kivy/pyjnius
Not exactly language bindings, but interface to a different programmable eco-system as well:
PyXXL (Excel Add-ins): https://www.pyxll.com/ PyUNO (OpenOffice/LibreOffice API): http://www.openoffice.org/udk/python/python-bridge.html

Maybe also add Cython to the list since it's sort of a Python-esque binding to the C API?

I would like to ask developers of Python bindings, FFIs and alternate C-API implementations for thoughts, suggestions, and pain points to help guide the future of the C-API.
[...]
If you know more, please let them (or me) know!
What seems like a lifetime ago, I fixed a number of memory handling issues with the Python R bridge, rpy. I haven't touched it in a decade, and the project seems to have forked:
- rpy2: https://rpy2.github.io/
participants (5)
-
Andrew McNamara
-
Brett Cannon
-
Marc-Andre Lemburg
-
Petr Viktorin
-
Simon Cross