On behalf of the Python Steering Committee, CPython core developer Thomas Wouters today announced an update on the PEP 703 proposal to make the Global Interpreter Lock optional in CPython.
He said that judging from the results of community polls on the no-GIL proposal , there is overall positive support. The Python Steering Committee therefore plans to accept the PEP 703 proposal and is currently working on the details.
Thomas Wouters presented the expected thinking of the Steering Committee:
- In the long run (maybe 5+ years), no-GIL builds should be the only builds . They don't want to create a permanent distinction between GIL present and no-GIL builds (and extension modules)
- Maintain backwards compatibility and avoid another Python 3 situation
- Need to see community support for it before committing to a full switch to no-GIL builds
- At any point before no-GIL was made the default, they would change their minds if it proved to be too disruptive for too little gain. Such a decision would likely mean rolling back all work, so no-GIL-specific code should be somewhat identifiable before deciding to make no-GIL the default.
Based on this, their development direction is divided into three phases:
- Shortly, add no-GIL builds as an experimental build mode , presumably in Python 3.13
- In the medium term, when they are confident that there is enough community support to make production use of no-GIL viable, they will support no-GIL builds, but not by default
- In the long run, they want no-GIL to be the default, and remove any traces of the GIL (without breaking backwards compatibility unnecessarily)
The PEP 703 proposal proposes adding a build configuration ( --disable-gil) to CPython that would allow it to run Python code without the global interpreter lock, and make the necessary changes to keep the interpreter thread-safe.
According to the description of the proposal, CPython's global interpreter lock (GIL) prevents simultaneous multi-threaded execution of code, which has become a major obstacle to improving the efficiency of Python code on multi-core CPUs.
