GeezerVison is showing github.com — Rename `Py_NOGIL` to a positive term · Issue #111863 · python/cpython
Rename Py_NOGIL to a positive term #111863DescriptionFrom 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
Activitycorona10 commented on Nov 8, 2023 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 commented on Nov 8, 2023 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 commented on Nov 9, 2023 up to Sam of course, but perhaps invert it completely, and go with something like Py_GIL or Py_WITH_GIL? colesbury commented on Nov 9, 2023 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 commented on Nov 9, 2023 Reacted by Hugo van Kemenade gvanrossum commented on Nov 9, 2023 Reacted by Dave Burkholder and Donghee Na hugovk commented on Nov 20, 2023 The SC decision: Py_GIL_DISABLED
I've updated the PR. added a commit that references this issue on Nov 21, 2023gh-111863: Rename blurb snippet placed in the wrong directory by acci…
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|