Hi Matti,
From the C API point of views, I see two main use cases:
Extend Python: performance doesn't really matter, the hotcode is not in the glue code but in the external code written in your favorite language (usually C). My plan is to use a portable ABI for different reasons.
Performance, "C accelerator": abuse "implementation details", private functions, access directly structure fields, etc. This code can be written by hand, or generate by tool like Cython.
These two use cases are not exclusive. You can easily imagine to produce two binaries (dynamic libraries) from the same source code, depending on a compiler option for example. I understood that Cython is already able to produce different code depending on options.
My goal is to make the "portable ABI" usable by more people. Currently, too few developers use the Py_LIMITED_API define (PEP 384, stable ABI).
Le mar. 18 déc. 2018 à 11:48, <matti.picus@gmail.com> a écrit :
Are these also goals?:
- allow introspection for JIT or AOT compilation of extension code as part of a larger unit, like Numba, Dask, or PyPy do
I only plan to add a *new* C API, but the old one remains available for people who need best performances.
Cython will still be able to access CPython internals, make assumptions on the implementation and use private functions.
You can already rely on PyPy internals to emit more efficient code. A new C API is not incompatible, it's just a different use case.
- enhance tooling like SIP, cython, pybind11,
Would you mind to elaborate? Which kind of problem are you trying to solve here?
Victor
Night gathers, and now my watch begins. It shall not end until my death.