Agreed--there needs to be discussion and thought about how this impacts library maintainers. How do they tell users their library supports or doesn't support non-GIL mode? Will pypi have new metadata to specify and enforce and projects dependencies support non-GIL mode, or is just a chaotic free for all where users have to figure that out themselves? How will a library author have one codebase that supports both GIL and non-GIL mode--will they effectively fork the code and maintain two codebases (yuck!) or will there be support for detecting GIL mode? How does this work for C extensions too? There's a ton of work to make this smooth for libraries and I really hope it is being thought through better than the python 2 to 3 story for library authors (which was no story and chaos).

Quoting my comment from elsewhere:

>I didn't dive deep on this, but I assume that GIL mode can still run anything, including no-GIL code (it is one of their promises, at least). So, unlike 2->3, there is forwards-compatibility.

>It also seems like the latter isn't meant as a replacement (for the moment), but rather as an option.

As long as GIL mode remains compatible with both old and new code, I see very little danger in having a no-GIL mode (besides hogging CPython maintainers' time).

I under-appreciated the forward comparability. So this partly a framing critique. If you’re going to frame it as “how this won’t be like before”, good to really highlight the how.

Indeed. Also once that Genie is out putting it back will be next to impossible.

quite a large set of users are using default python installation. There is large number of companies and non-trivial codebases that run on default python that comes with the oldest LTS version of Linux distro.

currently quite a lot of companies use python3.6 only because it comes standard with the Ubuntu 14.04.6 which happens to be the oldest LTS version - and companies have habit of migrating from out-of-support LTS version to currently-supported-oldest-LTS

this can repeat 2->3 because there will be users stuck with older versions of python and library maintainers will have to maintain both versions: with GIL and without GIL (just like PHP extension developers did with thread safe methods)

But shouldn't old GIL python versions be fine running code that is no-GIL compatible (assuming it is otherwise compatible)? Having a thread per process doesn't mean you cannot run code which is fine with having n threads per process. So if you maintain code which is otherwise compatible with e.g. python 3.6, after making it no-GIL compatible it should still be compatible to 3.6.