PEP 703 -- Decide on a replacement name for Py_NOGIL macro (or keep as is) #214
Description
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:
Activity
gvanrossum commented on Nov 9, 2023
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 commented on Nov 9, 2023
+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:
pitrou commented on Nov 9, 2023
Strong -1 on "multicore". This is really misleading and bordering on FUD.
pitrou commented on Nov 9, 2023
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 commented on Nov 9, 2023
"unlocked"?
gpshead commented on Nov 9, 2023
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:
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 commented on Nov 9, 2023
(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 commented on Nov 9, 2023
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 commented on Nov 10, 2023
@gpshead a macro like Py_GIL_ENABLED would not work well because it is not defined in older versions of Python:
gpshead commented on Nov 10, 2023
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 commented on Nov 10, 2023
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 commented on Nov 19, 2023
Okay, the SC discussed this and others on the SC just told me to be decide so lets go with Py_GIL_DISABLED.