Thanks Peter, that's a good clarification.
Simon's email about a possible future HPy backend for Cython also reminded me about a detail of the way pysip and cffi support the stable ABI: the modules built with those tools are abi3 compatible, but the support modules that the tools publish to PyPI are *not* abi3 compatible.
The key benefit of that approach is that it means the Stable ABI becomes usable even when the extension module needs access to a feature that's only in the full version dependent C API - the runtime support library just needs to wrap the relevant full API function(s).
If a HPy backend for Cython went in the same direction, that could significantly reduce the number of API functions that they needed to wrap.
Cheers, Nick.
On Wed, 24 Mar 2021, 8:24 pm Petr Viktorin, <encukou@gmail.com> wrote:
Hello list!
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: their own right.
- They are both incomplete, but useful *today* for some limited cases, and have lots of potential
- They need long-term effort, but most of the many steps are useful in
In addition to the use cases in PEP 652, the stable ABI *should* ideally be useful for: that couldn't afford to bundle Python.)
- bindings for non-Python software, where shoehorning Python into the buildsystem is not straightforward and building for several Python versions at once is not practical. Also, raw speed tends to not matter.
- GUI apps, whose scripting plugins could use any Python the user/scripter has installed. (Think Blender, if it was a smaller project
And here's some more concrete stuff. (Remember that these are still vague ideas):
Static
PyObjectandPyObject*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.
- Introduce a macro similar to the old PY_SSIZE_T_CLEAN that removes the
- This macro will give you access to a flag you can use to tell the runtime the extension is subinterp-safe.
- Python will support both the current, GIL-sharing subinterpreters, and isolated subinterpreters. (All signs say implementing this will be easy, relative to making subinterpreters always isolated and breaking existing code.)
- The macro will affect both the full API and the limited subset.
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org https://mail.python.org/mailman3/lists/capi-sig.python.org/ Member address: ncoghlan@gmail.com