Make C-API great for FFIs & non-C implementations

[encukou]

In C API strategy draft, there wasn't much opposition to the goal of being “easily usable from non-C languages”.
We should seek info on what this should mean from people who make FFIs, bindings and alternate C-API implementations.

Projects to ask:

• nanobind (should include bybind11 & Boost.Python experience)
  How can we make Python's C-API more friendly for C++? wjakob/nanobind#31
• PyPy
  https://mail.python.org/archives/list/[email protected]/thread/44IO4GHWBEVIXLFGD4SUNJKFDXOBHILE/
• PyO3
  How can we make Python's C-API more friendly for Rust? PyO3/pyo3#2346
• ctypes.pythonapi
  python-dev? look thru git history?

From MAL on capi-sig:

• 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/
  How can we make Python's C-API more friendly for CLR bindings? pythonnet/pythonnet#1797
• JPype (Java): https://github.com/jpype-project/jpype
  How can we make Python's C-API more friendly for Java bindings? jpype-project/jpype#1071
• 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/ (non-free)
• PyUNO (OpenOffice/LibreOffice API):
  http://www.openoffice.org/udk/python/python-bridge.html

And:

• PySide notes