The question was raised on another thread, so I figured I’d turn it into an actual topic and let people discuss the specifics of how the distribution should look.
My proposal:
sys.winver should be 3.x-nogil (which implicitly updates registry keys and default install directory names, as well as allowing py -V:3.x-nogil ... to launch it)
Installer becomes python-3.13.0-amd64-nogil.exe
Executables remain python.exe and pythonw.exe
DLLs remain python3x.dll and python3.dll
Installed shortcuts are Python 3.x (nogil) and IDLE (Python 3.x nogil)[1]
Notable omissions:
No modification to py.exe to support a short -3-nogil option (these are legacy flags now, the -V:... version is extensible)
At 3.13, no new Store packages are available. We do not release packages to the Store for experimental platforms/builds, to avoid the risk of users downloading them by mistake.
No 32-bit release of nogil (but it still builds in CI - winver="3.13-32-nogil", etc.)
Thoughts/concerns? What have I missed?
In effect, Bitness+="-nogil", so wherever the architecture would’ve appeared, it now includes -nogil↩︎
I am not a Windows user, but this sounds reasonable to for the N versions that nogil will be considered “experimental” and non-default.
What happens in version N+1? We flip everything to make nogil the default build in the store at the default install location, and the gilful build will not be on the store anymore and will have modified winver etc?
While the steering council is drafting our full response to PEP 703 for our official acceptance, one thing we’ve agreed upon in our discussions in the steering council:
We don’t want this to be known as “nogil” Python as a public moniker. That nickname:
does not communicate well to most non-core devs, people need not know what a GIL is.
contains a negative.
So we should also shift towards not using the term “nogil” ourselves to avoid confusion before we start making any releases.
A more appropriate term for this experimental in 3.13 build if you have a need to provide builds is “free-threading”. We realize “free-threading” doesn’t roll off the tongue like two-syllable “nogil” does, but it should be more understandable to people-who-are-not-us.
While I’m behind on my reading, @colesbury seems to have already picked up on the desire to use "t" instead of "n" in the other thread posted today that I believe this conversation spawned off of. (yay!)
Yeah, branding is basically the main question. I don’t have any preference (I’m quite happy with nogil myself), so will look to others to come to a consensus.
I’ve given examples in the original post of where the name has to fit. Some are user friendly (Start menu, version strings) and others are parts of directory names and should be short and lowercase, but still may be typed by users (e.g. in a py.exe option).
From a user’s perspective, there’s a pathway that needs to be taken when trying to solve a problem in order to realize that there’s current limitations imposed by the GIL.
Information about those limitations is already available online.
I think it will be harder to make a clear distinction between Multiprocessing, Threading, Free Threading, Multithreading and other variations as it’s not immediately clear that they addresses GIL limitations.
If the intent is not to disturb standard Python users and have separate experimental nogil releases until they become the default, the pathway towards the realization that one needs a nogil release is still the same and goes through available information where the issue is described as a GIL issue.
Therefore, I believe that nogil is more intuitive naming which is already familiar to existing users and will be easily understood by new users who will come from established information. In addition, new branding will spawn a whole new branch of information that addresses the same issue, which after nogil becomes the default will only add to confusion.
While I understand the objections to “nogil”, I don’t think “free-threading” is likely to be understood by people-who-are-not-us. It’s not a common programming or computer science term. Outside of Python core development, I’ve only seen the term frequently used as part of Microsoft’s COM.
I think this is a good name for the current efforts to improve Python’s multicore story, but doesn’t differentiate well between PEP 703 and per-interpreter GIL, which can be important in some contexts. (like build modes and ABIs). @eric.snow has been using this term for a while now.
I’m fine with nogil myself, but I’m also fine with trying to find another, term, as long as it’s fairly short.
I’m not sure that the argument “users don’t know what the GIL is” really holds – Python’s GIL has for decades been the target of very public criticism. I do agree that a positive term is slightly preferable over a negative one.
Personally, I’m less worried about coming up with a “branding”, what really matters in practical terms is having a short “tag” for use in things like versions - what would we use in place of “nogil” in 3.13-nogil?
A few days ago, I tried to explain ‘nogil’ to my daughter. She graduated with a CS minor about 8 years ago and now uses Python libraries in medical research programming – but likely has never used threads. We started with “Gil? What’s that?” I think she is typical of scientists who use Python.
Since she does things that may run a hour or two, she should benefit when numpy, scipy, pandas, nltk, pytorch, tensorflow, etc, automatically use multiple threads/cores when appropriate – when running on Python-ng or whatever.
There will be, but I don’t think we have settled on how (remember, the PEP is not officially accepted yet, just planned to be, and this is probably one of those little bits of detail the SC needs to decide if how the PEP lays it out makes the most sense or some other approach).
Thanks. I just noticed today that the --disable-gil flag has been added to configure on the main branch. Browsing the git log I see that’s currently the extent of nogil “support” at the moment.
Yeah that’s in to start laying the groundwork for things. Some buildbots have been setup, etc.
--disable-gil and nogil in buildbot names are all very much internal to the project that only those of us who build things ever see, it’s fine there. The real goal of avoiding n is to avoid abbreviating “no” or any other negative.
I totally understand why the suggestion of “free-threading” may not stick as a term and that “multicore” or “parallel” perhaps covers too many other possibilities. The thing to centralize around right now is probably just the lowly t hinting something to do with threading while we figure out what collective simple term gets used.
Nobody ever referred to Linux as Linux-noBKL (2.6+) or FreeBSD as FreeBSD-no-big-lock despite both of them (and many other projects) having gone through a de-single-lockification transition long after they were widely used.
This could be culturally dependent. I’ve observed that Japanese people use “NG” to mean “No Good.” My half-serious suggestion would be to use “NT” for New Technology.
Continuing my previous post: My daughter has already forgotten what ‘gil’ means and ‘ng’ has no meaning either. She suggested ‘mt’ for ‘ multi-threading’. ‘no-gil’ is really about ‘making multi-threading work the way we want it to’. Deleting gil is a means to that end.
I like naming challenges. Personally I think the ideal is: short, yet easy to be inspected for deeper meaning & references by those so inclined[1]. While there are surely many better naming choices still waiting to be discovered, I happened to stumble over this today:
3.13-gem (GIL Ex Machina; GIL’s Experimental Modification; Great Expansion of Multi-threading, etc.[2])
PS. I know, “gem” may sound like it’s from Ruby, but I doubt much of the Python ecosystem would really care (look, shiny!). And while there’s a package of that name on PyPI, it hasn’t seen a release in 6 years.
“free threading” fails both IMO, because there’s too many conflicting/confusing notions and resources about it to find a simple motivating reason for the name. ↩︎
Graceful Expectation Management; the list goes on… ↩︎
“nogil” is short, explicit and accurate, much more so than some confusing marketing brand such as “multicore Python” (what? Python didn’t allow multicore programming already?).
Everyone interested in the topic of parallelism in Python will have already heard about the GIL and how it constrains the options available.
today: