Good point. But “NT” reminds me of Windows NT, which by now, is old technology
“MT” sounds better in this respect. It could mean “multi threading” (but that’s not really accurate, since Python already does support multiple threads, it just cannot run Python byte code in parallel in those threads), or “more threads” (which gets us closer to the point, since Python can now run in more than one thread), or “many threads” (similar, with emphasis on scalability).
Some other ideas:
“Python PostGIL” (positive variant of removing the GIL)
“Python LT” (for “Python loves threads” or “Python likes threads”)
“Python CC” (for “concurrent Python”)
I personally don’t have a problem with “nogil” either - this will eventually be dropped anyway in a couple of years, similar to what we had with UCS2 and UCS4 Unicode variants of CPython some time ago.
Something I do wonder, though, is how all this is going to work out for code that has been written to work under both the GIL and the No GIL variants of Python. Would we be able to assume that nogil code will always run on the gil version of Python, so that we don’t need a flag saying “this works for both gil and nogil builds” ?
I don’t understand the debate about the name. For me, it’s clear that “nogil” in Python 3.13 will be highly experimental, it’s likely to be incomplete and crash, especially in 3rd party code. I would prefer that people have to pick the experimental “nogil” installer on purpose, rather than rebranding the current Python flavor as “legacy Python with a slow GIL”.
If nogil becomes a success (complete, stable, well adopted by the community), there is no problem: just make it the default, and remove the old experimental installer. It will just become “Python”. No suffix/prefix needed.
The SC plan is to make it the default in the long term, no?
I’ve no dog in this fight, but given past experience with other major changes (think 2-to-3), my guess is there will be people or organizations who want to continue to use Python with a GIL long after the core devs have switched to free-threaded/nogil/t/whatever, and perhaps well after support for the GIL has ended.
The natural alternative to “has GIL” is “has LUNG”. Perhaps “Python: Metamorphosis”, although this suggests that pythons are amphibians rather than reptiles…
In reality pythons don’t have gills at all[1], so PEP 703 is just correcting the situation to be more accurate.
like many animals they show the vestiges of gills during embryonic development…perhaps Python is finally being born? Certainly some will say that it’s growing up… ↩︎
Funnily enough, an echo of the BKL came up again in Kernel development recently, in the context of the effort to mainline PREEMPT_RT[1]. Some new infrastructure for that was originally named nobkl, and got now renamed to nbcon (non-BKL consoles). The final string makes no sense on its own; I mention this to underscore the amount of freedom we have in coming up with whatever makes sense for our constraints (e.g.: short, easy to remember, not defined as a negative, something that is not meant to be around long-term, etc.).
which needs some overhaul of the printk infrastructure, which had a BKL-like situation going on ↩︎
