PEP 703 -- Decide on a replacement name for Py_NOGIL macro (or keep as is)

[colesbury]

PEP 703 specifies that the Py_NOGIL macro designates --disable-gil builds. The steering council has written that they would "like a positive, clear term to talk about the no-GIL build".

I would prefer the steering council to decide on a replacement name (if any) because the community discussions have not reached any consensus about naming.

@hugovk has suggested a two possible replacement names:

• Py_DISABLE_GIL (which matches the --disable-gil configure flag)
• Py_FREE_THREADED

@gvanrossum suggested (in a comment below):

• Py_MULTICORE (with a corresponding --enable-multicore configure flag)

Whatever name is chosen will be used by C code as well as exposed through sysconfig.

Note that labeling the default (with GIL) build with a macro like Py_GIL or Py_WITH_GIL would not work well because it would not be defined in older versions of Python, and that would make writing the #if pre-processor guards more difficult for extensions that targets multiple versions of Python.

This is not super urgent, but it would be helpful to have a decision within the next few months before we start relying on the macro in C API extensions.

See also:

• Rename Py_NOGIL to a positive term cpython#111863
• gh-111863: Rename Py_NOGIL to Py_GIL_DISABLED cpython#111864
• https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075

[gvanrossum]

I propose to name the feature "multicore". I have used this to describe the proposal to a few folks who are highly technical but not into Python minutiae and it instantly makes it clear what we're talking about. We could start with --enable-multicore and Py_MULTICORE.

I just learned from the Discourse thread that OCaml calls it that too.

(Even though Wikipedia spells it "Multi-core Processor" I think that in common parlance the hyphen is going out of style for this particular concept, so I propose "multicore" as a single word.)

[hugovk]

+1 for hyphenless "multicore": I agree it's instantly understandable, much more so than "free threaded".

Multicore was also suggested in this Discourse thread and received many upvotes:

Branding

Branding is important. I suggest using the term “Multicore Python” for this effort instead of “nogil”. It sounds much more impressive, while “no GIL” is more obscure and negative. It worked for OCaml.

[pitrou]

Strong -1 on "multicore". This is really misleading and bordering on FUD.

[pitrou]

Even though Wikipedia spells it "Multi-core Processor"

The very fact that being multi-core is a property of CPUs (i.e. physical devices), not programming languages, should hint that this does not convey the right meaning.

[effigies]

"unlocked"?

[gpshead]

Personal take having observed some of our Discord chatter on this topic in the last month: I think we're fine with --disable-gil (and thus --enable-gil presumably being its opposite after a default flip if we were keep gil support around) as a configure flag. it is descriptive and this is only something cpython builders see anyways.

The C macro name is more interesting.

We should probably avoid Py_NOGIL there as this is something we expect users developing C Python extensions to see and use as a preprocessor define API? In that case I'd follow along the lines of what @hugovk was suggesting. Py_DISABLE_GIL is... close but still seems awkward as it has a negative in it making it a double negative when used with #ifndef. So why not Py_ENABLE_GIL or even better perhaps Py_GIL_ENABLED? ex:

#ifdef Py_GIL_ENABLED
// Older code take locking via the GIL for granted as we don't release it.
#else
// Modern code! maintain our own localized lock.
#endif

#ifndef Py_GIL_ENABLED
// "Our immediate concern is our family atomics. We must get them before the Harkonnens" - Dune
#endif

---

I'm also okay with Py_MULTICORE as a name. I don't find it to be misleading or FUD as @pitrou seems to (Antoine, can you explain that?). I realize threading concurrency issues exist just as much on a single cpu core as they do when you have multiple, but one of the reasons to enable such concurrency is to be able to make use of multiple cores so it does not feel to be too far off.

[gpshead]

(from the discuss thread given there is passion about the "multicore" term, i'd lean away from it from an SC community consensus decision point of view)

[pitrou]

I don't find it to be misleading or FUD as @pitrou seems to (Antoine, can you explain that?).

Python and its ecosystem already offer ways to fully exploit multicore setups, such as multiprocessing and concurrent.futures, but also Dask, Numpy, Numba, etc.

So this would be disparaging past and existing efforts, and misrepresenting what is possible using "traditional" CPython.

(it would also be woefully vague)

I think Py_GIL_DISABLED or Py_GIL_ENABLED would be fine.

[colesbury]

@gpshead a macro like Py_GIL_ENABLED would not work well because it is not defined in older versions of Python:

Note that labeling the default (with GIL) build with a macro like Py_GIL or Py_WITH_GIL would not work well because it would not be defined in older versions of Python, and that would make writing the #if pre-processor guards more difficult for extensions that targets multiple versions of Python.

[gpshead]

Good point (and me re-skipping pep bits too quickly). That'd also have applied to Py_MULTICORE (I presume nobody is going to suggest Py_SINGLECORE after that discussion). That points back to Py_DISABLE_GIL or Py_GIL_DISABLED if we don't decide to just stick with Py_NOGIL for the cpp macro.

[gvanrossum]

That'd also have applied to Py_MULTICORE

I don't see why. This would be undefined on older versions, only defined in 3.13+ on no-GIL builds, and eventually always be defined.

I'll leave it up to the SC to decide on the proper branding though. That's why I resigned as BDFL in 2018. :-)

[gpshead]

Okay, the SC discussed this and others on the SC just told me to be decide so lets go with Py_GIL_DISABLED.