PEP 779: Free-threaded Python is officially supported(docs.python.org)
docs.python.org
PEP 779: Free-threaded Python is officially supported
https://docs.python.org/3.14/whatsnew/3.14.html#pep-779-free-threaded-python-is-officially-supported
11 comments
Is this still something that must be enabled at compile-time, or will it be supported via a runtime flag?
Compile time. There are preprocessor #if guards all over the code base to provide different implementations for core operations. Many of these are used to provide a thread-safe version (e.g. atomic refcount). Presumably, these should work fine single threaded (assuming correctness). But at the moment they are compile-time, yea.
> With these recommendations and the acceptance of this PEP, we as the Python developer community should broadly advertise that free-threading is a supported Python build option now and into the future, and that it will not be removed without a proper deprecation schedule.
It looks like it still needs to be enabled at compile-time.
It looks like it still needs to be enabled at compile-time.
> Any decision to transition to phase III, with free-threading as the default or sole build of Python is still undecided, and dependent on many factors both within CPython itself and the community. This decision is for the future.
Compiler flag would be my guess.
Compiler flag would be my guess.
So we now have 2 official flavors of cPython 3.14 (since free-threaded is a different build than the current GIL-enabled default). I know there will "never" be a python 4, but I'm not sure that having multiple flavors is going to be any less confusing for users and library authors ...
OTOH, we now have `uv` to help keep the chaos under control, which really is a huge deal.
OTOH, we now have `uv` to help keep the chaos under control, which really is a huge deal.
PI-thon.
Can a pythonist help a rubyist brother out with a tl;dr? Are they removing the GIL? How does free threading differ from other threading paradigms?
You can read the details in PEP 703: https://peps.python.org/pep-0703/
TLDR: Yes.
As of this release, No-GIL/free threading Python has moved out of the experimental phase and is officially supported in this release. No-GIL Python is not the default for this release (that's potentially the next phase of the project), but running no-GIL/free threading is officially blessed.
As of this release, No-GIL/free threading Python has moved out of the experimental phase and is officially supported in this release. No-GIL Python is not the default for this release (that's potentially the next phase of the project), but running no-GIL/free threading is officially blessed.
I found it helpful to read the steering council's messages on this [1]. From my reading: yes, there is now an "officially supported" build of cPython without a GIL. But while it is "no longer experimental," it's still not the default.
From the SC's list of things that still have to be implemented or stabilized, it really doesn't sound production-ready! Specifically: the ABI is not stabilized yet; the documentation is not written yet; and most importantly, there are not yet "higher-level concurrency primitives that users can use safely and effectively".
[1] https://discuss.python.org/t/pep-779-criteria-for-supported-...
From the SC's list of things that still have to be implemented or stabilized, it really doesn't sound production-ready! Specifically: the ABI is not stabilized yet; the documentation is not written yet; and most importantly, there are not yet "higher-level concurrency primitives that users can use safely and effectively".
[1] https://discuss.python.org/t/pep-779-criteria-for-supported-...
[deleted]