Hmm so why does the new no-GIL Python have a separate build when it has a command line option to run with / without the GIL? Shouldn’t it just be one binary with GIL as default until all libraries migrated (a long time)?
@frabcus smell bad
@drj oh the situation smells bad! What’s the reasoin though?
@symroe @drj reading the PEP https://peps.python.org/pep-0703/ and comments on LWN https://lwn.net/Articles/939568/#Comments ...
I /think/ (not sure):
1. There is forwards *code* compatibility, so no-gil capable C modules code will just compile fine as gil-only easily.
2. There is binary incompatibility. So if you compile a no-gil version of a module, it won't work in the gil-only CPython binary. And vice versa.
So better than 2 to 3 as source code compatible. Sad that isn't binary forwards compat, so 2 module binaries