August 12th, 2024

GIL Become Optional in Python 3.13

Python 3.13 introduces an experimental feature to disable the Global Interpreter Lock (GIL), enhancing concurrency in multi-threaded applications, while allowing users to manage GIL status through various options.

Read original articleLink Icon
GIL Become Optional in Python 3.13

Python 3.13 introduces an experimental feature that allows the Global Interpreter Lock (GIL) to be disabled, enabling free-threaded mode. The GIL is a mechanism in CPython that restricts the execution of Python bytecode to one thread at a time. With the new version, users can opt to disable the GIL during installation by selecting the "free threaded binaries" option or by configuring the build with the `--disable-gil` option. This change allows for greater concurrency in multi-threaded applications. Users can control the GIL's status using the environment variable `PYTHON_GIL` or the command-line option `-X gil`. Performance tests indicate that while multi-threaded tasks show significant performance improvements without the GIL, single-threaded and multi-process tasks may experience some degradation. The ability to check the GIL status in the current interpreter is also provided, enhancing user control over threading behavior in Python applications.

- Python 3.13 allows optional disabling of the GIL for improved concurrency.

- The feature is experimental and requires specific installation configurations.

- Users can manage GIL status via environment variables and command-line options.

- Performance tests show improved multi-threaded execution but potential slowdowns in single-threaded and multi-process tasks.

- The ability to check GIL status is included in the new version.

Link Icon 14 comments
By @mort96 - 9 months
I kind of have the opposite feeling of many other people here... to me, Python is already pretty much perfect for my use, which is things like build scripts and random tools I make, plus it's used by a bunch of software I need to compile. The one big problem it has is that it keeps changing. I'll try to compile some dependency that I haven't updated in some time and I'll find that it fails to build because Python changed in some backward incompatible way. Or a tool I made will suddenly start printing deprecation warnings because Python has deprecated a library.

I get that for people for whom Python is their main language, all these changes make their lives better. But for me it kinda just gets in the way. Personally, I wish Python would continue to be maintained as is, but stop changing so much. Stop breaking my builds.

By @entropyneur - 9 months
Why are people building their software in Python when they need performance? There are other languages that excel at this. Python strengths lie elsewhere and they are increasingly being diminished with all these "upgrades". Splitting the ecosystem with async was already a major blow and now we are looking at another split along gil/non-gil axis. It's just sad.
By @ustad - 9 months
There is a certain beauty with the GIL and without it there will be more unnecessary complexity for the 80% of applications in the future and potential maintenance issues for current software.

To also enable this as default in the coming years is crazy.

I would love to hear what Guido thinks about this.

By @surfingdino - 9 months
Glad to see it, but it's early days and care is needed when porting existing code or writing new. There's also question of modules. Will those get updated? I am expecting a slow migration over the next couple of years. Python has made me money for over 15 years, but if I want to write code that can use all those cores and threads I use Golang.
By @XorNot - 9 months
Exciting! I'm going to be locking all my projects to --no-gil or whatever and targeting 3.13 by default as soon as possible.

Everytime I've needed just a bit of multicore performance and have gotten stuck using multiprocessing sucks - I'd much prefer just to use threading and not worry about the pickling process.

By @logicchains - 9 months
I'm really looking forward to PyTorch supporting this as it'll make writing custom dataloaders way easier, being able to use multiple threads directly rather than having to deal with all the wierd edge cases and copying that comes with multiprocessing.
By @jokoon - 9 months
I wonder if I will see Python as a browser scripting language in my lifetime
By @andy_xor_andrew - 9 months
Will -—disable-gil ever be the default that should be targeted by everyone? Or will python have “requires-gil” libraries and “allows-no-gil” libraries?
By @aardvark179 - 9 months
The world needs both more and less concurrency FUD. It needs more because too many people think their libraries are safe due to things like the GIL when they likely have bugs that will occur occasionally, and it needs less because that belief makes people terrified that removing the GIL will break their code.

If your pure Python code fails without the GIL it can probably fail with the GIL, and testing it without the GIL might help you find those bugs a lot quicker.

By @tgz - 9 months
After GIL they must add Result/Option and drop exceptions.
By @allanren - 9 months
It's good to see Python finally able to get rid of GIL. Looking forward to see how much performance can it improve.
By @Narhem - 9 months
Awesome to see Python turning more into a full fledged programming tool. Would be neat to see some kind of static typing, or atleast enforced duck typing.