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 PyObject and 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.

• 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