By Jake Edge
October 10, 2023

Back at the end of July, the Python steering council announced its intention to approve the proposal to make the global interpreter lock (GIL) optional over the next few Python releases. The details of that acceptance are still being decided on, but work on the feature is proceeding—in discussion form at least. Beyond that, though, there are efforts underway to solve that hardest of problems in computer science, naming, for the no-GIL version.

ABI concerns

In mid-September, Sam Gross, who authored PEP 703 ("Making the Global Interpreter Lock Optional in CPython"), posted a message to the Python discussion forum about the interaction of the PEP and the CPython stable ABI. In part, the stable ABI is used by extensions to enable their binary wheels to work with multiple CPython versions, thus not require rebuilds when CPython is released. The PEP envisions a path toward an eventual single CPython version without the GIL, but, in the meantime, there will be a build of the interpreter (using ‑‑disable‑gil) that can be used to test no-GIL operation.

Gross noted that extensions built for the stable ABI will not actually work with a no-GIL CPython 3.13 (which is due in October 2024), but he is proposing some changes so that extensions will work with both types of CPython builds from that version onward. Extensions that only call into the "limited" C API result in binaries that use the stable ABI, so Gross suggested a few additions and changes to the API in order to facilitate extension binaries that can work with both interpreter types (GIL and no-GIL). In part, it adopts the existing plan to switch some macros to function calls, in particular for incrementing and decrementing the object reference counts that are used for garbage collection.

Victor Stinner, who has done a lot of recent work on the stable ABI, replied that he thought there should a simple solution for extensions that can work on both interpreter types; he is concerned that the no-GIL experiment will fail otherwise. Because extensions that are built for the stable ABI on CPython 3.12 and earlier will not be compatible with no-GIL builds from 3.13 onward, he thinks it may make sense to create a new ABI version to differentiate the cases. Currently, the stable ABI is "abi3", but that could be bumped to abi4—even without moving to a Python 4. Many people seem to believe the ABI number and CPython major number are linked, but that is not the case.

Gross is less concerned about the need for extensions that want to support no-GIL mode having to build two separate binary wheel versions as he described in his original message. He believes that building two wheels is a manageable price to pay and is more worried about tying the no-GIL project to fixes or upgrades to the C API and stable ABI. Alex Gaynor agreed about the price; he has multiple packages with abi3 wheels (and "is very excited about the glorious nogil future") that would be affected, but creating two wheels is not overly burdensome as a one-time thing. He does want to ensure that existing and future versions of pip do the right thing in choosing between them, however.

Brett Cannon said that existing and older versions of pip would not do the right thing, unless a change to abi4 was made; the logic used in pip today would not be able to distinguish between the versions. Gross suggested that supporting older pip versions may not really be needed, since it is not an actual change in behavior:

I don't think we should worry too much about whether old versions of pip work properly for the experimental, --disable-gil build of CPython 3.13. As it is, old versions of pip frequently do not work with new versions of Python. For example, pip==23.1.1 and older (from just 5 months ago) will break if installed in CPython 3.13 (missing pkgutil.ImpImporter).

pip maintainer Paul Moore pointed out a difference, though: breakage is different from silently doing the wrong thing:

I think it's fine if an older version breaks for newer Python. But I'm less sure that silently installing the wrong package is acceptable. People do use older versions of pip, and loud breakages aren't the same as silent errors.

He noted that pip has a policy that users should always upgrade to the latest version, but that the project has no specific policy on silent errors of this sort. He is concerned that those who want to experiment with the no-GIL (or "free-threaded") builds will be put off if they end up "having to debug ABI compatibility issues like this". Gaynor agreed, noting that "pip silently doing the wrong thing creates a flood of issues" for the packages affected.

Barry Warsaw asked about whether there were plans for allowing installation of both interpreter types on the same system. Gross said that the situation was the same as having two different versions of Python installed. Warsaw thought that was reasonable and that it is not too difficult handle parallel installations. In the message linked above, Cannon said that one solution could be a "fat" wheel that had both binaries, as long as the names of those binaries in the wheel were distinct.

Naming

But the naming discussion got spun off into its own thread—once it clearly headed in that direction, anyway. Moore said that it was important to be able to install both interpreters so that people can easily test the no-GIL mode; if that is not straightforward to do, in Windows, macOS, Linux, and others, it will negatively impact the no-GIL project:

This links back to the packaging question, because how easy it is for users to try out nogil builds, and how easy it is for a user to select between nogil and gil, will strongly affect how much demand there is for nogil builds, and hence how much pressure there will be on package maintainers to provide nogil-compatible wheels in the first place.

Barry Scott wondered what names would be used, noting that the "shebang line" (i.e. "#!/usr/bin/python" or similar at the top of a script) needs to indicate which interpreter to invoke, which should the same across all of the platforms if possible:

The gil version of python executable is "python3". What is the name of the nogil executable? "python-nogil3", "python-nogil3.13" etc?

But the no-GIL build for 3.13 is clearly meant as an experimental feature, Gregory P. Smith said, which means that distributions should not be putting that build on the default $PATH, at least in his opinion. Smith is a member of the steering council, but noted that he was using his "personal reply hat". Having a lengthy name for the interpreter that lingers for long periods afterward because it remains in shebang lines is not desirable, so he suggested waiting:

In effect this defers any potential install naming decision until 3.14 or later once we've got some practical knowledge of how things are working out - we'll presumably know better at that time if there's a need for parallel installs. It's okay for some things like this to be decided later, in effect that is why PEP-703 has an Open Issues section not fully specifying this area today.

But Fedora developer Petr Viktorin pointed out that distributions are likely to want to package the no-GIL interpreter for their users to experiment with. Moore agreed that users are going to want that:

I would like to be able to write scripts with #!/usr/bin/env python3.13-nogil (or something like that) in order to get the free threaded build without needing to hard-code a long and probably non-intuitive path (which on Windows is also user-specific).

In another thread that was started by Steve Dower, who creates the official Python packages for Windows, Smith noted that the steering council has agreed that it wants to avoid the name "nogil" to describe the build. With his council hat on, he said that there were two reasons behind this decision: it "does not communicate well to most non-core devs, people need not know what a GIL is" and it contains a negative. There is a suggested alternative:

A more appropriate term for this experimental in 3.13 build if you have a need to provide builds is "free-threading". We realize "free-threading" doesn't roll off the tongue like two-syllable "nogil" does, but it should be more understandable to people-who-are-not-us.

That set off some predictable bikeshedding on naming, with several in the thread noting that they think "nogil" is the better choice—or at least that they are perfectly happy with that name. Gross thought that the suggested alternative was confusing: "While I understand the objections to 'nogil', I don't think 'free-threading' is likely to be understood by people-who-are-not-us." He noted that the term is not widely used elsewhere. Most participants generally just wanted to use something short—"nogil" was the clear "winner" in that department—but none of the suggestions made there seemed to resonate. The one concrete change was to switch the ABI tag for the no-GIL builds from "n" to "t" (for "threading"). Excising "nogil" at this point is going to be something of an uphill climb, it would seem.

Proposing abi4

Back in the original thread, there was some discussion, mostly between Viktorin and Gross, about problem areas in the API changes that Gross proposed. That led to a new proposal that incorporated the feedback and adopted the idea of creating a new ABI, abi4. Gross has developed a prototype of the new ABI. Viktorin is generally in agreement with the approach, though some details still need to be worked out.

One of those details is that a PEP for abi4 is needed, as Stinner pointed out. Viktorin agreed ("This is a pre-PEP discussion.") and it would seem that the mid-October core developer sprint will be the venue for some face-to-face discussions on the topic. In particular, there is confusion about the compatibility guarantees provided by the combinations of various limited API versions and abi3, which will impact what will happen with abi4. Research on those issues is ongoing.

So, work on the no-GIL (or free-threaded) version of CPython is proceeding apace, but the final acceptance of the PEP is still pending. It is somewhat surprising that there has been such a lengthy delay, but PEP 703 and its knock-on effects are likely to dominate CPython development—and ecosystem—over the next five or more years, so the steering council wants to make its acceptance criteria clear. As council member Thomas Wouters put it: "we're ironing out the exact acceptance text (we want to clarify a lot of our decisions)". Some of that work may happen at the sprint as well.