Python is a high-level programming language.
The news recently broke that the The Python Project Steering Committee has announced its desire to approve the Python language extension proposal «PEP-0703″, making the global interpreter lock optional in CPython and which basically defines the embed of CPython compile mode without Global Interpreter Lock (GIL).
PEP-0703 defines to stop using GIL by default, but add build option “–sin-gil” to disable it. How are youl The new mode is expected to solve the problem with parallelization of operations on multi-core systems, caused by the fact that the global lock does not allow parallel access to shared objects from different threads.
It is mentioned that in the long term (after 5 years), shell is planned to be changed by default to only in global non-locking mode, while at the same time dropping support for compiling with GIL.
Thank you all for responding to the survey on the no-GIL proposal. It is clear that the general sentiment is positive, both for the general idea and for the PEP 703 in particular. The Board of Directors is also largely positive on both. We intend to accept PEP 703, although we are still working out the details of acceptance.
As we have done a few times in the past, we want to communicate our intention to accept the PEP along with our current thinking on the details related to acceptance.
Besides that, It is mentioned that the changes that are planned to be carried out in three stages, which are short, medium and long term. Given that in the first stage, disabling GIL by default is impractical due to the overhead associated with changes to the garbage collector, the memory management system, and the primitives for organizing locks. For example, due to the use of reference counting for thread isolation, there is a performance drop for single-threaded scripts (in the pyperformance test suite by 10%). At the same time, it may be necessary to disable the GIL in scientific computing, for which the lack of parallelization is a more serious problem than the linear speed of code execution.
In the second stage, basically the confirmation will be awaited. and that there is sufficient support from the community so that the use of "non-GIL is viable" and make sure that GIL-less build is supported but not default.
In the last stage, no-GIL will already be the default value and any vestiges of GIL will be removed (without unnecessarily breaking backwards compatibility).
It is observed that work to move away from GIL will be done very carefully so as not to repeat the mistake what happened when promoting Python 3: A non-GIL build will need to ensure compatibility with older versions of Python, and any third-party code changes required to work on non-GIL builds should also work on GIL builds.
There are no plans to renumber the versions to Python 4 for non-GIL builds, as they will maintain ABI compatibility.
Throughout the process, we (the core developers, not just the SC) will need to re-evaluate progress and suggested timelines. We don't want this to become another ten-year backward compatibility fight, and we want to be able to cancel PEP 703 and find another solution if it seems to become problematic, so we need to regularly check that continued work is worth it.
We hope this provides some clarity on the future of the PEP as we work out the exact details of acceptance. The SC will work to finalize the acceptance in the coming weeks.
Before the full transition to non-GIL builds, we plan to achieve full community support for these builds, as well as provide additional C APIs and Python APIs to enable safe multithreading in existing code.
Finally, as already mentioned, it is expected that the transition to the third stage can occur in at least 5 years and the probable date for PEP-0703 is the release of Python 3.13, scheduled for next fall.
If you are interested in knowing more about it, you can check the details In the following link.