Python’s Steering Council Plans to Make Its ‘Global Interpreter Lock’ Optional
Python’s Global Interpreter Lock “allows only one thread to hold the control of the Python interpreter,” according to the tutorial site Real Python. (They add, “it can be a performance bottleneck in CPU-bound and multi-threaded code.”)
Friday the Python Steering Council “announced its intent to accept PEP 703 (Making the Global Interpreter Lock Optional in CPython), with initial support possibly showing up in the 3.13 release,” reports LWN.net.
From the Steering Council’s announcement:
It’s clear that the overall sentiment is positive, both for the general idea and for PEP 703 specifically. The Steering Council is also largely positive on both. We intend to accept PEP 703, although we’re still working on the acceptance details…
Our base assumptions are:
– Long-term (probably 5+ years), the no-GIL build should be the only build. We do not want to create a permanent split between with-GIL and no-GIL builds (and extension modules).
– We want to be very careful with backward compatibility. We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed). This is not Python 4. We are still considering the requirements we want to place on ABI compatibility and other details for the two builds and the effect on backward compatibility.
– Before we commit to switching entirely to the no-GIL build, we need to see community support for it. We can’t just flip the default and expect the community to figure out what work they need to do to support it. We, the core devs, need to gain experience with the new build mode and all it entails. We will probably need to figure out new C APIs and Python APIs as we sort out thread safety in existing code. We also need to bring along the rest of the Python community as we gain those insights and make sure the changes we want to make, and the changes we want them to make, are palatable.
– We want to be able to change our mind if it turns out, any time before we make no-GIL the default, that it’s just going to be too disruptive for too little gain. Such a decision could mean rolling back all of the work, so until we’re certain we want to make no-GIL the default, code specific to no-GIL should be somewhat identifiable.
The current plan is to “add the no-GIL build as an experimental build mode, presumably in 3.13… [A]fter we have confidence that there is enough community support to make production use of no-GIL viable, we make the no-GIL build supported but not the default (yet), and set a target date/Python version for making it the default… We expect this to take at least a year or two, possibly more.”
“Long-term, we want no-GIL to be the default, and to remove any vestiges of the GIL (without unnecessarily breaking backward compatibility)… We think it may take as much as five years to get to this stage.”
Read more of this story at Slashdot.
Python’s Global Interpreter Lock “allows only one thread to hold the control of the Python interpreter,” according to the tutorial site Real Python. (They add, “it can be a performance bottleneck in CPU-bound and multi-threaded code.”)
Friday the Python Steering Council “announced its intent to accept PEP 703 (Making the Global Interpreter Lock Optional in CPython), with initial support possibly showing up in the 3.13 release,” reports LWN.net.
From the Steering Council’s announcement:
It’s clear that the overall sentiment is positive, both for the general idea and for PEP 703 specifically. The Steering Council is also largely positive on both. We intend to accept PEP 703, although we’re still working on the acceptance details…
Our base assumptions are:
– Long-term (probably 5+ years), the no-GIL build should be the only build. We do not want to create a permanent split between with-GIL and no-GIL builds (and extension modules).
– We want to be very careful with backward compatibility. We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed). This is not Python 4. We are still considering the requirements we want to place on ABI compatibility and other details for the two builds and the effect on backward compatibility.
– Before we commit to switching entirely to the no-GIL build, we need to see community support for it. We can’t just flip the default and expect the community to figure out what work they need to do to support it. We, the core devs, need to gain experience with the new build mode and all it entails. We will probably need to figure out new C APIs and Python APIs as we sort out thread safety in existing code. We also need to bring along the rest of the Python community as we gain those insights and make sure the changes we want to make, and the changes we want them to make, are palatable.
– We want to be able to change our mind if it turns out, any time before we make no-GIL the default, that it’s just going to be too disruptive for too little gain. Such a decision could mean rolling back all of the work, so until we’re certain we want to make no-GIL the default, code specific to no-GIL should be somewhat identifiable.
The current plan is to “add the no-GIL build as an experimental build mode, presumably in 3.13… [A]fter we have confidence that there is enough community support to make production use of no-GIL viable, we make the no-GIL build supported but not the default (yet), and set a target date/Python version for making it the default… We expect this to take at least a year or two, possibly more.”
“Long-term, we want no-GIL to be the default, and to remove any vestiges of the GIL (without unnecessarily breaking backward compatibility)… We think it may take as much as five years to get to this stage.”
Read more of this story at Slashdot.