Rename Py_NOGIL to a positive term

[hugovk]

From the PEP 703 acceptance:

We want to avoid negatives in terms and flags and such, so we won’t get into double-negative terrain (like we do when we talk about ‘non no-GIL’). We’d like a positive, clear term to talk about the no-GIL build, and we’re suggesting ‘free-threaded’. (Relatedly, that’s why the build mode/ABI letter is ‘t’ and not ‘n’; that change was already made.)

Py_NOGIL is a user-facing macro, let's rename it to something positive.

Maybe Py_DISABLE_GIL or Py_FREE_THREADED?

cc @colesbury

Linked PRs

• gh-111863: Rename Py_NOGIL to Py_GIL_DISABLED #111864
• gh-111863: Rename blurb snippet placed in the wrong directory by accident. #112300
• gh-111863: Rename term Py_NOGIL to Py_GIL_DISABLED in sysconfig #112307

[corona10]

Maybe it will affect to #111571, Sam may need to make decision what should go first :)
But I agree with updating the term to follow SC's decision anyway.

[hugovk]

Yep, fully defer to Sam to merge things in whatever order he likes, including closing #111864 if he wants to do it another way.

[itamaro]

up to Sam of course, but perhaps invert it completely, and go with something like Py_GIL or Py_WITH_GIL?

[colesbury]

I commented on @hugovk's PR (#111864 (comment)).

Macros like Py_GIL or Py_WITH_GIL do not work well because they are not defined in older versions of Python (or pypy). That would make writing the #if pre-processor guards more difficult for extension code that targets multiple versions of Python.

[colesbury]

I put an issue in the steering council GitHub repo: python/steering-council#214

[gvanrossum]

I propose "multicore".

[hugovk]

The SC decision: Py_GIL_DISABLED

• PEP 703 -- Decide on a replacement name for Py_NOGIL macro (or keep as is) steering-council#214 (comment)

I've updated the PR.