Skip to content

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

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

Description

@colesbury
colesbury
opened on Nov 9, 2023

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

  1. gvanrossum commented on Nov 9, 2023

    @gvanrossum
    gvanrossum
    on Nov 9, 2023
    Member

    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.)

  2. hugovk commented on Nov 9, 2023

    @hugovk
    hugovk
    on Nov 9, 2023
    Member

    +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.

  3. pitrou commented on Nov 9, 2023

    @pitrou
    pitrou
    on Nov 9, 2023
    Member

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

  4. pitrou commented on Nov 9, 2023

    @pitrou
    pitrou
    on Nov 9, 2023
    Member

    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.

  5. effigies commented on Nov 9, 2023

    @effigies
    effigies
    on Nov 9, 2023

    "unlocked"?

  6. gpshead commented on Nov 9, 2023

    @gpshead
    gpshead
    on Nov 9, 2023
    Member

    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.

  7. gpshead commented on Nov 9, 2023

    @gpshead
    gpshead
    on Nov 9, 2023
    Member

    (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)

  8. pitrou commented on Nov 9, 2023

    @pitrou
    pitrou
    on Nov 9, 2023
    Member

    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.

  9. colesbury commented on Nov 10, 2023

    @colesbury
    colesbury
    on Nov 10, 2023
    Author

    @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.

  10. gpshead commented on Nov 10, 2023

    @gpshead
    gpshead
    on Nov 10, 2023
    Member

    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.

  11. gvanrossum commented on Nov 10, 2023

    @gvanrossum
    gvanrossum
    on Nov 10, 2023
    Member

    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. :-)

  12. gpshead commented on Nov 19, 2023

    @gpshead
    gpshead
    on Nov 19, 2023
    Member

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

  13. gpshead
    closed this as completedon Nov 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions