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.

I&#x27;m going to admit that what I really want to see is a strong push to standardize and fully incorporate package management and distribution into python&#x27;s core. Despite the work done on it, it&#x27;s still a mess as far as I can see, and there is no single source of truth (that I know of) on how to do it.<p>For that matter, pip can&#x27;t even search for packages any more, and instead directs you to browse the pypi website in a browser. Whatever the technical reasons for that, its a user interface fail. Conda can do it!!!!! (as well as just about any package management system I&#x27;ve ever used)

Every single HN thread on python performance, ever:<p>Person with limited to zero experience with CPython internals&gt; I hate the GIL, why don&#x27;t they <i>just remove it</i>?<p>That <i>just</i> is doing an incredible amount of heavy lifting. It&#x27;d be like saying, &quot;Why doesn&#x27;t the USA <i>just</i> switch entirely to the metric system?&quot; It&#x27;s a huge ask, and after being burned by the 2&#x2F;3 transition, the python team is loathe to rock to boat too much again.<p>The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice.<p>Whatever your monday-morning quarterback idea on how to pull out the GIL is, I can almost guarantee, someone has thought about it, probably implemented it, and determined it will have one or more side effects:<p>- Reduced single-thread performance<p>- Breaking ABI&#x2F;FFI compatibility<p>- Not breaking ABI immediately, but massively introducing the risk of hard to track concurrency bugs that didn&#x27;t exist before, because GIL<p>- Creating a maintenance nightmare by adding tons of complexity, switches, conditionals, etc to the codebase<p>The team has already decided those tradeoffs are not really justifiable.<p>The GILectomy project has probably come the closest, but it impacts single-thread performance by introducing a mutex (there are some reference type tricks [1] to mitigate the hit, but it still hurts run time 10-50%), and necessitates any extension libraries update their code in a strongly API-breaking way.<p>It&#x27;s possible that over time, there are improvements which simultaneously improve performance or maintainability, while also lessening the pain of a future GILectomy, e.g. anything which reduces the reliance on checking reference counts.<p>[1] PEP 683 is probably a prerequisite for any future GILectomy attempts, which looks like it has been accepted, which is great <a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0683&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0683&#x2F;</a>

Notably yesterday Guido posted an update on the Faster Python plans w.r.t. the no-GIL plans (<a href="https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;pep-703-making-the-global-interpreter-lock-optional-3-12-updates&#x2F;26503&#x2F;118" rel="nofollow noreferrer">https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;pep-703-making-the-global-inter...</a>) specifically:<p><pre><code> Our ultimate goal is to integrate a JIT into CPython</code></pre>

Can someone give a good argument of why subinterpreters are an interesting or useful solution to concurrency in Python? It seems like all the drawbacks of multiprocessing (high memory use, slow serialized object copying) with little benefit and higher complexity for the user.<p>The nogil effort seems like such a better solution, that even if it breaks the C interface, subinterpreters aren&#x27;t worth considering.

Looks cool. This caught my eye<p>&gt; C++ and Java developers expect to be able to run a program at full speed (or very close to it) under a debugger.<p>I haven&#x27;t worked in Java too much, but in C++ I don&#x27;t remember having this expectation

Building a whole new interpreter and accompanying compiler tiers is a <i>lot</i> of work, still in 2023. Many different projects have tried to make this easier, provide reusable components, to offer toolkits, or another VM to build on top of. But it seems that none of these really apply, we&#x27;re still at the &quot;every language implementation is a special snowflake&quot; territory. That&#x27;s partly the case in Python just because the codebase has accumulated, rather nucleated, around a core C interpreter from 30 years ago.<p>IMHO the Python community has intentionally torpedoed all competing implementations of Python besides CPython to its own detriment. They seem to constantly make the task of making a compatible VM harder and harder, on purpose. The task they face now is basically building a new, sophisticated VM inside a very much non-sophisticated VM with a ton of legacy baggage. A massive task.

From the pip on subinterpreters:<p>&gt;&gt; In this case, multiple interpreter support provide a novel concurrency model focused on isolated threads of execution. Furthermore, they provide an opportunity for changes in CPython that will allow simultaneous use of multiple CPU cores (currently prevented by the GIL–see PEP 684).<p>This whole thing seems more like something developer wants to do (hey, it&#x27;s novel!) than something users want. To the extent they do want it, removing the GIL is probably preferable IMHO. That a global lock is a sacred cow in 2023 seems strange to me.<p>Maybe I&#x27;m misunderstanding, but I don&#x27;t want an API to manage interpreters any more than I want one for managing my CPU cores. Just get me unhindered threads ;-)

This is extremely exciting stuff. Thank you for Python and working on improving its performance.<p>I use Python threads for some IO heavy work with Popen and C and Java for my true multithreading work.

The beauty of the GIL was that it made writing good python libraries easy, from the utility perspective. Python is such an amazing multi-tool because of its rich library.<p>Personally I&#x27;d like to see Python continue as the amazing multitool that it is has always been.<p>Go is the natural concurrency sibling for Python. High performance parts of Python applications should be linked to Go binaries, or simply be written entirely in Go.<p>Ideally Go linkage would be highly integrated into Python. There is a huge place in the world for GIL constrained Python. Enabling Python to push further into high performance environments is just going to make a problem worse.

&gt; Experiments on the register machine machine are complete<p>This is a worthwhile watch on this topic: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;cMMAGIefZuM" rel="nofollow noreferrer">https:&#x2F;&#x2F;youtu.be&#x2F;cMMAGIefZuM</a>

Speaking of Python, as a beginner I have tried to grasp Classes and Objects and watched countless YouTube videos and Reddit&#x2F;StackOverflow comments to understand them better but I&#x27;m just banging my head against the wall and it&#x27;s not sticking. The whole __init__ method, the concept of self and why it&#x27;s used, instance and class variables, arguments, all of it. When learning something, when you simply cannot grasp a concept however hard you try, what&#x27;s the course of action? I have tried taking breaks but that&#x27;s not helping.

&gt; PEP 669 – Low Impact Monitoring for CPython<p>Finally, 15 years later Python might also get something similar to VisualVM.

How multithreaded programs depend on the GIL rather than use proper locking? The No GIL project might break a lot of multithreaded apps.

Ruby team approached parallelism &amp; multicore in a cool way, they introduced the concept of the Actor model (like Erlang)!

Just one question: Do you realy want Python to be held back by the GIL 10 years from now? If not, when do you want to start the change? If so, what do you think a CPU will look like in 10 years, and how would a GIL Python facilitate getting value from it?

How would this (or any of the recent changes) affect popular web frameworks like Django &#x2F; Flask &#x2F; FastAPI? Would this increase performance in serialization or speed in general?

This is exciting. Feels a little like JavaScript 10 years ago.

Wish python would sort out their packages mess and let there be one and only one (obvious) way to do it.

I&#x27;m actually rooting for RustPython to reach a level of maturity that we&#x27;d just be able to ship apis and stuff with it.... <a href="https:&#x2F;&#x2F;github.com&#x2F;RustPython&#x2F;RustPython">https:&#x2F;&#x2F;github.com&#x2F;RustPython&#x2F;RustPython</a>

Just add some PR spin like JS did and declare the GIL a feature.

Many projects start out in Python b&#x2F;c often new libs are python-first. Many of those run into performance issues and eventually determine that Python will never be fast b&#x2F;c of the GIL.<p>I think it&#x27;s very magnanimous of the python team, by not removing the GIL, to give Go, Java and C++ a chance.