2017-07-13 0:23 GMT+02:00 Stefan Behnel firstname.lastname@example.org:
From a Cython perspective, it's (not great but) ok if these "implementation details" were moved somewhere else, but it would be a problem if they became entirely unavailable for external modules. Cython uses some of the internals for performance reasons, and we adapt it to changes of these internals whenever necessary.
I don't want to break the Python world, or my project will just fail. For me, it's ok if Cython or even numpy use the full CPython C API with structures and macros to get the best performances. But we need something like the PEP 399 for C extensions: https://www.python.org/dev/peps/pep-0399/
The best would be if C extensions would have two compilations mode:
* "Optimize for CPython" (with impl. detail) * "Use the smaller portable C API" (no impl. detail)
For example, use the new private Python 3.6 _PyObject_FastCall() if available, but fallback on PyObject_Call() (or other similar function) otherwise.
Once we are are to compile in the two "modes", it becomes possible to run benchmarks and decide if it's worth it. For extensions written with Cython, I expect that Cython will take care of that. The problem is more for C code written manually.
The best would be to limit as much as possible to "optimized code" and mostly write "portable" code.