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.
Speaking for GraalPy, this is no longer correct, we felt that we had to add a GIL to improve our compatibility with existing Python code. There were two main issues we had, both of which the PEP mentions:
a) What are the atomicity expectations around builtin types and their operations (IronPython and Jython answer the question what to lock in builtinListA.extend(builtinListB) differently, for example.) In my opinion, the clarifications around these alone would be very valuable from this PEP.
b) To get the C extensions in the ecosystem around NumPy to work, we needed either locking or patching. We observed issues around memory corruptions and plain wrong behaviour. And as was previously mentioned on this thread, without a thorough audit of the code of all extensions we run, we also felt great trepidation about what threading bugs may lurk even if we patched the issues we found. We initially looked into a GIL around calls to C extensions, but so many of our targeted workloads then needed to lock anyway that we saw little benefit. In this regard, too, we would benefit from this PEP if it pushed extensions to declare how thread-safe they are.