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.
> 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.
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.
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.
- [deleted]