If PEP 703 is accepted, Meta can commit three engineer-years to no-GIL CPython

Removing the GIL will <i>not</i> break the vast majority of existing Python code. Here&#x27;s the backwards compatibility section of PEP 703:<p><a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0703&#x2F;#backwards-compatibility" rel="nofollow noreferrer">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0703&#x2F;#backwards-compatibility</a><p>That section is short and I encourage you to read it in full. Here&#x27;s what it says about how removing the GIL affects existing Python code:<p>• Destructors and weak reference callbacks for code objects and top-level function objects are delayed until the next cyclic garbage collection due to the use of deferred reference counting.<p>• Destructors for some objects accessed by multiple threads may be delayed slightly due to biased reference counting. This is rare: most objects, even those accessed by multiple threads, are destroyed immediately as soon as their reference counts are zero. Two places in the Python standard library tests required gc.collect() calls to continue to pass.<p>That&#x27;s it with respect to Python code.<p>Removing the GIL <i>will</i> require a new ABI, so existing C-API extensions will minimally need to be rebuilt and may also require other changes. Updating C-API extensions is where the majority of work will be if the PEP is accepted.<p>This will be an opt-in feature by building the interpreter using `--disable-gil`. The PEP is currently targeted at Python 3.13.<p>This is nothing like the Python 2 &gt; 3 transition.

It’s an interesting debate ( money aside ). In the past 15 years, at least to my eyes, one of the most important changes in soft eng culture has been the now systematic search for correctness. Systematic, organized, large scale Testing is one side of the coin, but the real value , and significantly more important change to me is guarantees&#x2F;proofs : static analysis, stronger type systems, etc. So type annotations in Python, typescript, rust instead of c++, etc. Tools as well : golang race detector, infer, coverity, pvs studio, code peer (Ada)&#x2F;spark, compcert, etc.<p>In this particular case, I understand that removing the Gil would create potential new risks ( but provide better performance) and although tooling is mentioned, it’s not officially part of the plan, so it feels like a regression of some sorts.

PEP 703 mentions the multiprocessing module which I used recently with great success. It is essentially message passing parallelism, i.e. the actor model. I would think even with the GIL removed message passing is still the best approach for a higher-level language, like Python, to handle parallelism as it is conceptually simple and lock free.<p>The primary disadvantage of the multiprocessing module is it uses separate processes which means my resource heavy Python extension needs to be duplicated multiple times in memory (at least on Windows). I think the move to supporting threads means the module could leverage them instead of separate processes, avoiding the need to duplicate C extensions in memory, and thereby reducing the overall memory pressure on a system.

&gt; If PEP 703 is accepted, Meta can commit to support […] between the acceptance of PEP 703 and the end of 2025<p>Meanwhile, the Steering Council is dragging their feet, even though so many people in the community have chimed in their support for nogil being a thing (in the linked thread and two others).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;steering-council&#x2F;issues&#x2F;188#issuecomment-1575106739">https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;steering-council&#x2F;issues&#x2F;188#issuec...</a>

There&#x27;s a great talk by David Beazley (I don&#x27;t remember which one) that he basically explains that removing the GIL isn&#x27;t difficult at all. After all, it&#x27;s just one lock.<p>The issue is all the libraries and packages that were built around it. It&#x27;s now been YEARS of building on top of the GIL.<p>So anyways, PEP 703 is a a nice effort, but I doubt we (everyday mortals) can enjoy it. Meta, and big companies with a specialized team might be able to exploit it by making sure their entire stack is GIL-free.<p>EDIT: My bad, the talk is from Larry Hastings: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=P3AyI_u66Bw">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=P3AyI_u66Bw</a>

Over time I&#x27;ve changed my mind regarding the GIL. Now I think it&#x27;s existence actually is a good thing, since it makes a lot of things easy and robust by default.<p>The subinterpreters route sounds really promising since it strikes a good balance between allowing those that need same-process parallelization to be able to do so and keeping the status quo (like workers in Javascript).<p>I&#x27;d actually veto PEP 703 at this point, since the Python optimization team is making good progress, and this could actually take them back a bit, while diverting too much energy into a low-reward avenue.

Might be worth changing the title to &quot;no-GIL&quot;. My first thought was &quot;What is nogil CPython?&quot; - thinking it was some specialized fork of CPython. I guess you could say that is technically true. I was previously aware of the GIL in Python, yet it still didn&#x27;t occur to me immediately.

Whatever happens, I&#x27;m hoping we won&#x27;t see another 2to3-like migration. I moved from Python a long time ago due to its multi-threaded limitations (among other things) to Java and JVM, and I really appreciate the stability the JVM team tries to maintain. Things are not perfect, but I&#x27;d take stability&#x2F;compatibility over perfection any day.

Seeing so many comments about how hard it is to just break compatibility and upgrade is sad. Instead of just throwing our hands up and saying it’s too hard, we could adopt the model the JavaScript ecosystem has seen more of which is codemods that upgrade the code for us.<p>If as a community we invest in those tools and make them easier to build, the cost of upgrading goes down and the velocity of high-impact changes can increase.

Why waste effort on speeding up the old CPython interpreter rather than working on PyPy, an actual compiler? [1] &quot;On average, PyPy is 4.8 times faster than CPython 3.7&quot;<p>[1] <a href="https:&#x2F;&#x2F;www.pypy.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.pypy.org&#x2F;</a>

So generous!<p>The FAANG etc failed me for anything open source sponsorship related.<p>Their business depends on it, they made a fortune out of it, yet they donate little or nothing to it, or worse, they forked it and was reluctant to upstream anything.<p>pick Amazon randomly, it went from exploiting to rip-off in my opinion, thanks to its boss , who sails on a luxury yacht and asks all his employees to be frugal. they all look similar to me as far as supporting OSS goes.

This is a delicate issue. As guido stated (<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;19" rel="nofollow noreferrer">https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;pep-703-making-the-global-inter...</a>):<p>&gt; If there’s one lesson we’ve learned from the Python 2 to 3 transition, it’s that it would have been very beneficial if Python 2 and 3 code could coexist in the same Python interpreter. We blew it that time, and it set us back by about a decade.<p>So it&#x27;s not so easy to decide to go with again 2 different versions of Python.<p>I understand how caution they are.<p>However, this commitment from Meta, complemented with MS financing Guido, and the quality of Sam Gross proposal makes me optimistic.

It&#x27;s three engineer years until 2025, and it&#x27;s just a person mentioning on the discuss board. It sounds a bit weird to throw something like this in a public forum.

PEP 703 will add the option to disable GIL (default is on). More context here: <a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0703&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0703&#x2F;</a>

Sorry, stupid question, can someone tell, please, how do other interpreted languages deal with problem similar to GIL or noGIL?

In the big picture three engineer years are nothing. I bet Meta has spent 30 engineer years on no-poke Facebook.

10 years late. I remember being criticized for avoiding the GIL in some CPython C code in 2012 and I think I stopped contributing to CPython after that. There are (or were back then), curmudgeons trying to hang on to their &quot;safe layer over 90s style C process&quot; Python.<p>This is a great step forward.

The GIL problem won&#x27;t be solved by throwing engineer hours at it (not even Meta engineers). Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions with innocent things like accessing a dictionary item or incrementing a value. It&#x27;s a massive education and legacy code problem at least on the same scale as the python 2 to 3 migration.<p>I honestly don&#x27;t think the community is ready for this change and don&#x27;t expect to ever see stock cpython drop the GIL--perhaps there will be a flag to selectively operate a python process without the GIL (and leave the onous on you to completely test and validate your code works with potentially new and spooky behaviour).

&gt; Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions<p>Except for every single piece of python I have ever written which will continue to work just fine.

Just to clarify, this is three engineer years. Meaning a cumulative of 3 years over all engineers.<p>I fail to see why this is a big deal. Don&#x27;t big tech companies contribute much more to python FOSS

As someone not particularly tuned into the Python ecosystem, what is &quot;nogil&quot;, though?

to be honest... we already saw that the migration from python2 to python3 was a complete shitshow, but the value python brings is so great the ecosystem survived.<p>i would gladly accept a python3 to python4 breaking change where all the necessary bits are changed to get real multi-threading (no-gil, gilectomy or whatever).<p>it&#x27;s just so worth it.

It&#x27;s crazy how much work we put into trying to speed up these scripting languages. It&#x27;s the same with Ruby. Shopify spends tons of dev resources on making JIT and stuff.

Hopefully Mojo makes good progress offering a good alternative

i get that it would feel nice to have real multithreading, but if i want real multithreading with python i just use xonsh to pipe in bash<p><i>insert bell curve meme</i>

I am curious how much of the python community the GIL affects? And is Facebook&#x27;s interest related to AI performance?

Don&#x27;t Meta maintain their own fork?

After many years. GIL is fine to me, it is not a problem at all.

Python 5000, why not.

The editorialized title &quot;Meta pledges Three-Year sponsorship for Python if GIL removal is accepted&quot; seems misleading at best. The actual wording was:<p>&gt; support in the form of three engineer-years [...] between the acceptance of PEP 703 and the end of 2025<p>It seems much more like them pledging engineer time from Meta employees to work on this project than sponsorship, not a monetary sponsorship like the title implies.

I believe you want to link to <a href="https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;a-fast-free-threading-python&#x2F;27903&#x2F;99" rel="nofollow noreferrer">https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;a-fast-free-threading-python&#x2F;27...</a> (comment #99, the most recent right now.)

The title is highly editorialized and links to a comment that has nothing to do with the sponsorship.<p>Direct link to the comment, where Meta offers to commit to working on this issue for 3 person-years: <a href="https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;a-fast-free-threading-python&#x2F;27903&#x2F;99" rel="nofollow noreferrer">https:&#x2F;&#x2F;discuss.python.org&#x2F;t&#x2F;a-fast-free-threading-python&#x2F;27...</a>

This is potentially problematic. It creates a conflict of interest: will the GIL proposal be accepted based on technical merits and potential benefits to the Python community overall, or just because the Python foundation wanted money? The problems that Meta faces in production are not necessarily the problems faced by every Python developer. In particular, Meta might value performance more than backwards-compatibility, while other Python users might feel differently. If Meta were to offer unconditional support, that would clearly be good for Python; attaching conditions to their support makes the situation trickier to navigate.

Evil response. Say, &quot;Sure!&quot; and release python v4 with their feature request, and watch the python split wars happen all over again &gt;:-}

I just get a bad feeling about this &quot;gift&quot;

Just rewrite all of your Python in Go. Python in 2023 is a mistake.

They committed <i>three person-years</i>, not three years. This project would need dozens of person-years over a three year period.<p>Also a comment on Github is not a binding support contract. Meta executives could deprioritize this project at any time... hell the person making the commitment could already be laid off, we have no clue. As someone who worked in big tech for a long time, trust me - it needs to be in writing with an exec signature.

I can&#x27;t even imagine how many engineering years it would require to fix just the most used libraries that expect the gil to exist. I assume 3 years wouldn&#x27;t even cover the actually interpreter, throw in the library piece and how is this useful?

20+ years later, and billions of lines or python code later, the GIL discussion is still there. Kind of an amazing mess of a problem… mainly shows the priority of python being a ducktape type solution from the start.

Latest decade in software engineering indicate that multi-processing is much preferable over multi-threading. It&#x27;s the architecture Edge, Firefox, and Chrome uses. So the question is what use cases multi-threading address that are not already covered by multi-processing? The memory overhead that multiple processes cause is relatively insignificant on recent machines with 32GB+ of ram.

I think at this point it is better Meta to ditch python and invest in a new programming language that mimics exactly wording for wording of python but without GIL. Google did it with their Carbon for C++, Go for C&#x2F;D&#x2F;C++. Microsoft even wrestle with Java for .NET and at one point their J++ 2 decades ago. Meta shpuld create their own. Maybe dump their resources into Modular. Python at this point is basically a C++ with a hotch potch of features and codebase. Start from clean like Mozilla Rust would help entire programming a lot than invest in a niche subset feature of Python which they dont have any control at all (I am speaking from corporate point of view). Python is like Perl, it will continue to have its place even decades later to be generic or niche for AI. But the rest of us may be moving on to something more specialized and cleaner like Rust, Ruby, Modular, etc.