There is a roadmap for improving the C-API at https://pythoncapi.readthedocs.io/roadmap.html
From my reading of the information there, it seems there are a number of goals to the refactoring:
- allow compile-once c-extensions that would be binary compatible with more than one version/flavors of python
- hide python internals
- which would make writing c-extensions less bug-prone (refcounting semantics, breaking refernence cycles)
- which could unleash possible performance gains
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
- enhance tooling like SIP, cython, pybind11,
What do you think? Is this an accurate summary of the goals?
On 2018-12-19 12:18, Nick Coghlan wrote:
> Remember that we don't hear from happy users of a feature - we only
> hear from users for whom the feature is incomplete.
There are also a lot of happy users of the non-limited API who simply do
not see the need for the limited API.
On 2018-12-18 11:48, matti.picus(a)gmail.com wrote:
> - enhance tooling like SIP, cython, pybind11,
I don't think that this is really part of the goal. I would say that
these tools put constraints on *how* the refactoring is done (rather
than *why*): whatever changes to the C API are made, it should not
affect badly those tools.