gh-108223: Refer to PEP 703 as Free Threading

[vstinner]

Rename support.Py_GIL_DISABLED to support.FREE_THREADING.

• Issue: Add --disable-gil option to configure #108223

---

📚 Documentation preview 📚: https://cpython-previews--112780.org.readthedocs.build/

[vstinner]

cc @colesbury @corona10

Should the Py_GIL_DISABLED macro be renamed to Py_FREE_THREADING?

See the steering council decision: python/steering-council#221 (comment)

[corona10]

cc @hugovk

[corona10]

We already changed the term from Py_NOGIL to Py_GIL_DISABLED.
Do we have to touch this term all things one more time?

See PRs of #111863

[corona10]

Ah okay, python/steering-council#221 (comment) was announced 2 hours ago.

[vstinner]

Do we have to touch this term all things one more time?

Naming is hard :-) The update is that the Steering Council took a decision. But this PR is not about Py_GIL_DISABLED macro which can be renamed in a following PR if needed.

[itamaro]

I'm confused. Didn't the SC decision explicitly mention that Py_GIL_DISABLED is ok?

[corona10]

I have the same opinion as @itamaro
Except for updating build information from nogil to freethreading, the rest of the things do not need to be updated.

[hugovk]

Should the Py_GIL_DISABLED macro be renamed to Py_FREE_THREADING?

See the steering council decision: python/steering-council#221 (comment)

No, we keep Py_GIL_DISABLED for the macro.

The SC said yesterday:

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.

python/steering-council#221 (comment)

This PR doesn't touch the macro though. It changes a constant used by unit tests. This isn't exposed to users, so we could keep it as is, but are also free to change it.

However, because the constant is directly looking up the macro value from sysconfig, I'd think I'd prefer to keep them the same.

[hugovk]

?

Suggested change

	build.append("freethreading")
	build.append("gil_disabled")

[vstinner]

I updated the PR. Please review it again.

No, we keep Py_GIL_DISABLED for the macro.

Oh ok. I read the announcement too quickly, I missed the part about Py_GIL_DISABLED.

However, because the constant is directly looking up the macro value from sysconfig, I'd think I'd prefer to keep them the same.

Ok, I updated my PR for that.

@hugovk proposed build.append("gil_disabled"). From what I understood, anything displayed to the user should not associate free threading with negative term such as "disabled". I prefer to reuse the "official term": "free threading". I added an underscore for readability: build.append("free_threading").

[vstinner]

Merged, thanks for reviews.