Our Plan for Python 3.13
The &quot;Faster Python&quot; team are doing a fantastic job, it&#x27;s incredible to see the progress they are making.<p>However, there is also a bit of a struggle going on between them and the project to remove the GIL (global interpreter lock) from CPython. There is going to be a performance impact on single threaded code if the &quot;no GIL&quot; project is merged, something in the region of 10%. It seems that the faster Python devs are pushing back against that as it impacts their own goals. Their argument is that the &quot;sub interpreters&quot; they are adding (each with its own GIL) will fulfil the same use cases of multithreaded code without a GIL, but they still have the overhead of encoding and passing data in the same way you have to with sub processors.<p>There is also the argument that it could &quot;divide the community&quot; as some C extensions may not be ported to the new ABI that the no GIL project will result in. However again I&#x27;m unconvinced by that, the Python community has been through worse (Python 3) and even asyncIO completely divides the community now.<p>It&#x27;s somewhat unfortunate that this internal battle is happening, both projects are incredible and will push the language forward.<p>Once the GIL has been removed it opens us all sorts of interesting opportunities for new concurrency APIs that could enable making concurrent code much easer to write.<p>My observation is that the Faster Python team are better placed politicly, they have GVR on the team, whereas No GIL is being proposed by an &quot;outsider&quot;. It just smells a little of NIH syndrome.