I’m still curious about the perf impact of making container GetItem return a reference that is autoreleased at the next thread state release, as removing possible GetItem unsafety would make me feel much better about C extension safety during a nogil transition. PEP 703: Making the Global Interpreter Lock Optional - #87 by lunixbochs
There’s another possible transition method - enable the GIL per thread by default, but allow opting out of the GIL for specific threads (rather than all or nothing for the whole program) from either a C API function or a with context manager. This may be able to reduce any possible safety impact at first to nogil opt in users rather than all cpython users, and buys time to work out possible edge cases. This makes it less necessary to have a --disable-gil compile flag or separate pypi interpreter name as well.
Can the ABI changes necessary for nogil happen independently of the SC deciding on nogil itself being merged to the main interpreter? That’s a much smaller change and would allow C extensions to be compatible with both interpreters long before nogil is included.
(FWIW the realtime improvements from GIL removal are so compelling for me that I’m investigating switching to it even before a cpython merge)