Python's GIL removal is a poison pill and benefits Mojo
A major criticism of the Python programming language is that it can't thread across cores. The reason is because of the CPython's Global Interpreter Lock (GIL).
The inability to take advantage of more than one core in a multi-CPU system seriously limits Python performance. It's one of the reasons why Python embarrassingly lags its peers when it comes to speed and efficiency.
Developers have begged Python's stewards for almost 30 years to fix the GIL. With the steering committee's recent acceptance of PEP 703, it looks like Python's GIL removal might happen.
It's a bad idea.
Python's GIL is a poison pill
Removing Python's GIL is a poison pill. It will inevitably kill off Python as we know it.
Every piece of Python code that runs on the CPython interpreter assumes safe, single-threaded execution. Removing Python's GIL changes that assumption. Every library or Python program ever written that might be impacted by multithreaded data access will have to be retested and potentially rewritten.
Amid the transition from GIL to no-GIL Python runtimes, existing Python projects will likely have to maintain two codebases: one for GIL-based runtimes and another for where Python's GIL is removed. That promises to be a nightmare for open-source projects for which maintaining a single distribution is difficult enough.
Furthermore, the removal of the GIL will have negative impacts that extend beyond the boundaries of Python's interpreter.
Due to its many shortcomings, Python is seldom used to implement actual machine learning routines or run neural networks. Python's main use case is to simply format and massage input data as well as feed it to functions and routines that are implemented in languages such as C++ or Java that are more capable of threading across cores.
However, those functions expect to be invoked in a safe and single-threaded manner. Many of those programs that Python interacts with will require extra tests, updates and dual maintenance as well.
Python 2 to 3 all over again
All of this should feel familiar to maintainers of Python libraries. They were forced to do something similar with the fumbled switch from Python 2 to Python 3, when the stewards of the Python language turned their backs on the community and abandoned backwards compatibility.
During the Python 2 to 3 debacle, developers had little choice but to submit to the dictates of the language stewards and migrate. They received little lead time about the backwards incompatibility issues, but because no viable alternatives existed at the time, organizations that were heavily committed to Python were forced into expensive and disruptive Python version migrations.
Python fans likely have little appetite to go through that again for the GIL-to-no-GIL transition.
Fortunately, things are different now. The GIL's removal is slated to take five years, and my guess is it will take longer. Developers and architects will have time to plan around this change, and if they perform due diligence, their plans should involve completely porting away from Python.
Mojo to the rescue
The Mojo programming language didn't exist when developers struggled with the hastily forced move to Python 3. But it does now, and it will become the de-facto target runtime if Python swallows the no-GIL poison pill.
Mojo's creators knew that it's difficult to teach an old dog new tricks, so they built Mojo to fully support Python code. Just paste Python code into a Mojo file, and it not only runs, but it also immediately runs multiple times faster.
Furthermore, Mojo works across the entire AI stack, from the CUDA cores on the GPU to the CPU-bound Python scripts that run on the desktop. C and C++ functions that will require updates to support multi-threaded Python code can be written in Mojo as well.
Many of the most popular, open-source machine-learning libraries are already ported to Mojo. Why would anyone who supports a Python project not do the same, if the stewards of the Python language once again force an unnecessary rewrite of all your working code?
I've always said that once the first, full-increment release of Mojo arrives, no greenfield AI or ML projects will be written in Python. All new projects will be developed using a Mojo-first approach, because coding against a CPython runtime won't make sense anymore.
Similarly, if Python removes the GIL, project leaders forced to reckon with rewrites and the long-term prospects of their codebase's health will move to Mojo as well. It will simply be negligent not to do so.
Slow at runtime and slow to adapt
Many developers in the Python community are frustrated with the language's slow evolution. Discussion of finally removing the GIL after 30 years has understandably excited them, but in their excitement over finally being heard, they fail to see the big picture.
The removal of Python's GIL is a poison pill that will kill the language and send users fleeing to higher ground and to the Mojo language. So long as Mojo presents a fast, efficient and professionally maintained alternative, the Python community should leave the GIL well enough alone.
Darcy DeClute is a technical trainer and Agile coach who helps organizations apply Scrum-based principles to adopt a modern DevOps stack. She is a certified Professional Scrum Master, Professional Scrum Developer and Professional Scrum Product Owner as well as author of Scrum Master Certification Guide.