Please decide a name for PEP 703 (nogil)

[encukou]

Hello,
The community discussion about the name for PEP 703 (nogil) experimental builds is not going anywhere at this point:

• https://discuss.python.org/t/37075
• https://discuss.python.org/t/39064
• https://discuss.python.org/t/34049

Please paint this bikeshed.

At least the Fedora PR to provide the experimental build is, AFAIK, blocked on this – providing a name that will change would not be very useful.

[DanielNoord]

This feels very similar to #214.

Could the macro name be turned into a name as well? gil-disabled?

[gpshead]

It wasn't immediately obvious, but I think you're really seeking answers to two/three questions: (please correct me if I'm wrong)

Qa: What term should be used in a third party distributor (Fedora, etc) package name if they offer an experimental configure --disable-gil build of the cpython runtime?

Qb: What should the name of the installed configure --disable-gil python executable be?

That Fedora PR appears to currently be using the term freethreading:

(1) within the package names:

+ %package -n python%{pybasever}-freethreading
+ Summary: Free Threading (PEP 703) version of the Python runtime

(2) and it appears to install it as /usr/bin/python3.13-freethreaded:

+ %if %{with freethreading_build}
+ %files -n python%{pybasever}-freethreading

(3) and also a /usr/bin/python3t:

+ # Analog of the core subpackage's files:
+ %{_bindir}/python%{LDVERSION_freethreading}

I personally think that the freethreading name used in (1) and (2) make sense as reasonable answers to Qa and part of Qb. Though I encourage updating the Summary text in (1) to call the package Experimental Free Threading ... to help make it clear to anyone looking at the package of the experimental status.

Regarding (3) as the other part of Qb: As we're in the experimental phase, I think it is better not to offer a generic python3t style convenient executable name at all. This is more of a gut feeling, but the short f"python{sys.version_info.major}{sys.abiflags}" style un-versioned name could be seen to imply it has long term support and stability over time which is not a claim we should appear to make while we are in the experimental phase.

Philosophy: The presence of a specific version in an executable name suggests "change will be required" to people using the name, its absence implies "this will always work" stability.

The CPython project does not really have power over distributors in these regards. We can only offer advice on what we'd prefer to see.

Those are my immediate personal opinions. I'll keep this open while this is discussed among the rest of the SC.

I assume there's sort of a Qc third question hiding beneath the above in terms of "will we be providing --disable-gil binaries as official python.org downloadable installers?" as if we did, we'd need to use answers to Qa and Qb above ourselves. Right now as of 3.13.0a2 we do not appear to be doing that based on what I see on https://www.python.org/download/pre-releases/

[willingc]

freethreading makes sense. It would probably be good to be consistent and avoid variants like free-threading, freethreaded, etc.

One thing to consider is how long we wish to continue using no-gil in branch names, code, etc. Having no-gil and freethreading will be confusing for users.

Whatever name is selected, a very brief explanation of what the name signifies would be helpful. Brief as in 1-2 sentences. Along with a possibly a FAQ:

• What is freethreading?
• Where can I find more information about it?
• How do freethreading and Faster CPython coexist?
• Where do they differ
• What do we mean by experimental
• Will there always be two versions or will they combine in the future?

[gvanrossum]

Not to be confused with freebasing. :)

[keszybz]

freethreading does make sense, but this does not make it a good name. A good name something that is unique, memorable, and possible to pronounce. "Free threading" is a mouthful, with a confusing alliteration, and relatively hard to spell, esp. for non-native speakers. I also think it's completely opaque: quite a lot of people know that Python has the GIL, so "no gil" has some intuitive meaning to many users. "Free threading" is a new term with no connotations. So it'd be better to use a short memorable name, and put the longer descriptions and explanations in the docs.

Please just call this nogil.

[encukou]

@gpshead, I was asking for a name that could be used everywhere -- Qa, Qb, but also things like blog posts talking about the PEP-703 builds. Should it be “free threading”, “multicore”, “nogil”, “parallel”, “unlocked”, “NG”, “MT”, “gem”, “postGIL”, “LT”, “CC”, “Lung”, ...?

As for specific executable names (and existence), you do have good points, but

• I expect that discussion to be much less heated; ideally the SC shouldn't need to be involved there.
• It would be really nice to have the final name for the feature itself, so the discussion about /usr/bin/python3.13-XYZ vs. /usr/bin/python-XYZ vs. /usr/bin/python3.13t isn't derailed by deciding what XYZ should be.

[hroncok]

(2) and it appears to install it as /usr/bin/python3.13-freethreaded:

+ %if %{with freethreading_build}
+ %files -n python%{pybasever}-freethreading

No, the python3.13-freethreading here is the name of the package, not the name of the file. Currently, the PR only installs it as /usr/bin/python3.13t (not even /usr/bin/python3t).

[hroncok]

I also noticed that we are already confusing "freethreaded" with "freethreading". That's one reason this name is not ideal.

[gpshead]

SC PEP-703 interpreter package and executable naming decision

• As far as the installed executable name goes, keep python3.13t. That has the version and the t matches the ABI letter. That is consistent with past Python ABI binary names. Lets not have a generic python3t so long as we're in "experimental" phase as is the case for 3.13 until a future SC is asked to declare otherwise based on future core dev consensus on Discuss when the time feels right.

• Package or Installer names. Use the freethreading term within the package or installer name. We expect that term is likely to persist there so long as both types of interpreter builds are supported by the project.

In conversational places about the interpreter, expect to see the terms "free threading" and "free threaded". We realize the English word endings for verb (ing) and past participle (ed) forms (if I'm even naming the grammar terms correctly) may seem annoying so some, but when used in contexts like discussions and documentation this is going to happen naturally. They are an accurate description.

Within code, we can use technical implementation detail terms in names. Thus #214's Py_GIL_DISABLED #define and the --disable-gil configure flag making sense. Those are not typically exposed to users.