Thank you for the detailed comments Eric. I’ll try to address some of the questions and comments that I can answer now.
how much work to update the no-gil branch to the main (i.e. 3.12) branch?
It’s hard to give a precise estimate. The last rebase (3.9.0a3 to 3.9 final) took months of work, but that involved substantial rewrites as well. Maybe 2-5 months of work?
how does the proposal affect other Python implementations (will they be expected to support multi-core threads)?
Generally, no – the PEP is specific to CPython. Implementation that closely track CPython may wish to do so. For example, my colleagues on Cinder have expressed interested in integrating the changes after they’re adopted upstream. I would not expect PyPy to do so, but that’s up to the PyPy developers. IronPython, Jython , and GraalVM python already do not have a GIL.
EDIT: correction from Tim Felgentreff regarding GraalPy.
will there be a new modulespec slot (see PEP 489) to indicate support for no-gil?
No, I think the ABI flag is sufficient. C API extension authors need specifically build for the --disable-gil variant, so a modulespec slot seems redundant to me.
how will pip be affected?
PIP is not affected. I’m using PIP in the nogil fork and it works great. (There is a small difference, but I don’t think it matters: the fork modifies the Python tag as well as the ABI tag, while the PEP only proposes modifying the ABI tag.)
the proposed solution negatively impacts … extension module maintainers
There are also substantial benefits to extension module maintainers. The PEP includes quotes from a number of maintainers of widely used C API extensions who suffer the complexity of working around the GIL. For example, Zachary DeVito, PyTorch core developer, wrote “On three separate occasions in the past couple of months… I spent an order-of-magnitude more time figuring out how to work around GIL limitations than actually solving the particular problem.”
extension module maintainers … may have to maintain dual implementations of some code
I think if you examine the patches to extensions from the nogil for, you’ll see that they are quite small and there aren’t too many dual code paths.