After the e-mails from the previous week, I set up a call with Eric to sync on Limited API/Stable ABI issues. The higher-bandwidth (and more emotion-friendly) medium worked great for us, but unfortunately, everyone else was excluded. Here are some rather unstructued notes from my point of view. They might be good discussion starters :)
Please read PEP 652 “Maintaining the Stable ABI” for my thoughts, plans and rationales for the short term.
For the long term, there are some more vague plans and ideas:
There's not a 1:1 mapping between “Limited API”, “Stable ABI” and “C-API, the Good Parts™”, *but* unless you're deep in this space, it makes sense to conflate them. I aim to make them converge.
I intend to focus my CPython time on Limited API/Stable ABI for the next... few years, probably.
The work I'm doing (extension isolation & now stable ABI) is similar to the subinterpreters effort in several ways:
and have lots of potential
their own right.
In addition to the use cases in PEP 652, the stable ABI *should* ideally be useful for:
buildsystem is not straightforward and building for several Python versions at once is not practical. Also, raw speed tends to not matter.
user/scripter has installed. (Think Blender, if it was a smaller project that couldn't afford to bundle Python.)
And here's some more concrete stuff. (Remember that these are still vague ideas):
PyObject* are the main thing in the Limited API
that's blocking subinterpreters. We see no other blockers.
A possible way to solve this is to make isolated subinterpreters support *opt-in* for extension modules:
problematic items from the headers.
runtime the extension is subinterp-safe.
isolated subinterpreters. (All signs say implementing this will be easy, relative to making subinterpreters always isolated and breaking existing code.)