LWN: Comments on "Progress on no-GIL CPython"

Progress on no-GIL CPython

estansvik — Fri, 27 Oct 2023 17:20:08 +0000

Easy, Python = GIL is on, Pythoff = GIL is off

Progress on no-GIL CPython

remow — Sat, 21 Oct 2023 13:34:20 +0000

Python-unlocked!

Progress on no-GIL CPython

mirek — Sat, 21 Oct 2023 09:48:26 +0000

Use -ng suffix.
No-Gil for people who don't mind.
Next-Gen for people who don't like negatives.

Progress on no-GIL CPython

jonaso95 — Fri, 20 Oct 2023 22:34:52 +0000

People are absolutely traumatized from the python2->3 transition - any major version bump will be perceived as a massive, nerve-wrecking, never ending migration process (even though in reality it wouldn't be)

Progress on no-GIL CPython

sammythesnake — Fri, 20 Oct 2023 12:52:47 +0000

Or indeed "not-GIL-T" (with the T standing for "threading") :-D

Progress on no-GIL CPython

jepsis — Thu, 19 Oct 2023 20:01:16 +0000

Considering renaming 'nogil' to 'ng' would be a good idea. It also hints at 'next generation', which remains relevant.

Progress on no-GIL CPython

NRArnot — Fri, 13 Oct 2023 09:15:23 +0000

Precisely my first thought. Python4 should be defined as python-nogil. The Python language is the same for both versions, and future language additions would stay in step i.e. python3.15 and python4.15 would always run the same pure Python code without issues.

BUT using a different abi, so python3 libraries won't necessarily be available under python4 to start with (or sometimes, never).

A long, LONG way down the road, python3 might be retired, because there's nothing significant left that python4 can't do.

Progress on no-GIL CPython

tsr2 — Fri, 13 Oct 2023 08:46:52 +0000

Would it be helpful to have the name flag that this is an experimental version? Abbreviating no gil to ng would allow users who don't understand no gil to assume it's next generation. That give us the name python-expt-ng.

Progress on no-GIL CPython

stephanlachnit — Fri, 13 Oct 2023 04:31:21 +0000

Just because this was the case, doesn't mean that has to be true for Python 4 as well. Python 3 has removed stdlib modules, which is already a breaking change.
While I agree that tagging a new version without some testing is not helpful, but I hope that they eventually just tag it Python 4.

Progress on no-GIL CPython

carlosrodfern — Thu, 12 Oct 2023 04:32:37 +0000

python-gilless!!

Progress on no-GIL CPython

NYKevin — Wed, 11 Oct 2023 19:20:28 +0000

> [...] but that loading such a module makes multithreaded performance even worse than 3.5 with respect to contention, due to causing everything to require a global and less subtle lock.

That is not a compatibility break. That is a quality of implementation issue. If the code still works and gives the right answer in a somewhat-believable* amount of time, then it is compatible. The question is whether this is a good or a bad tradeoff to make, not whether it will break anything. Offering two versions of the interpreter (or better yet, a flag/environment variable) would be one way to mitigate that issue, but they might instead reasonably decide that maintaining both versions is not worth the effort.

* I'm not going to precisely define "somewhat believable amount of time," but if performance on a modern system is comparable to the previous version on hardware released within the 21st century, then that's probably good enough. If it runs like a PDP-11, then that's probably too slow.

Progress on no-GIL CPython

iabervon — Wed, 11 Oct 2023 18:34:19 +0000

It seems entirely plausible that every C module written for 3.5 and recompiled for each later version will end up working fine with a Python that makes the no-gil implementation the normal one, but that loading such a module makes multithreaded performance even worse than 3.5 with respect to contention, due to causing everything to require a global and less subtle lock. On the other hand, programs using libraries not updated to deal well with the new interpreter probably don't use threads and don't care.

Progress on no-GIL CPython

NYKevin — Wed, 11 Oct 2023 16:28:27 +0000

IMHO it's not time for that *yet.* A major version bump will, rightly or wrongly, be interpreted as a promise that nogil will definitely land in mainline at some point in the near future, and that doing so will necessarily break backcompat. Based on how it is described in this article, I don't think the work is far enough along yet to make either of those promises:

* It may turn out that nogil only offers a performance win in a narrow set of circumstances that are atypical of most Python code, and so nogil Python becomes a separate, non-default mode of the interpreter, and relatively few programs actually use it in practice.
* It may turn out that a future version of the interpreter is able to create some sort of coarse-grained locking scheme that is "good enough" to be backwards compatible with "most" C extensions, perhaps requiring at most a simple recompile.
* It may turn out that nogil is so costly and infeasible that the work is dropped entirely. It doesn't currently look like it's trending in that direction, but development timelines are notoriously hard to predict.
* It may turn out that a major version bump is the best way to express nogil's effect on the Python ecosystem, but they can cross that bridge when they come to it.

Progress on no-GIL CPython

ericproberts — Wed, 11 Oct 2023 14:15:27 +0000

It's a major backwards-incompatible change given the number of python libraries written in C. A major version increase would indicate python users might need to do some extra work to upgrade, even if just bumping up dependency versions -- and, let's be real, some libraries will just fall out of use instead of become nogil-compatible, so upgrading won't *necessarily* be straightforward. No need to pretend that isn't what this is.

And there's nothing wrong with major version upgrades that require most users to do some work to upgrade. It's just the previous upgrade made python scared of its own shadow.

Progress on no-GIL CPython

danielthompson — Wed, 11 Oct 2023 08:20:24 +0000

nogil is essentially a change to the CPython implementation rather than the Python language. Adopting python4 would imply for many people that the releases included major incompatible language changes similar to what happened in python2 to python3.

Progress on no-GIL CPython

iabervon — Wed, 11 Oct 2023 06:17:41 +0000

Or Strang, who got a two month head start on Gil retirement.

Progress on no-GIL CPython

jengelh — Wed, 11 Oct 2023 05:58:03 +0000

Nah, "not gill" is quite in line with Python tradition.

Progress on no-GIL CPython

csigler — Wed, 11 Oct 2023 00:57:56 +0000

Obviously, the proper code name should be "Gunderson":

https://simpsons.fandom.com/wiki/Gil_Gunderson

As to an official name, that's above my pay grade.

Progress on no-GIL CPython

ringerc — Tue, 10 Oct 2023 22:09:54 +0000

Probably because it doesn't actually directly affect most Python code. Unless you're using the C API it's (generally) not going to impact you much, if at all.

Progress on no-GIL CPython

TheGopher — Tue, 10 Oct 2023 21:37:00 +0000

Why not just python4 then? Seems like a logical cut-off point.