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

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/