4 ms·

PEP 779: Free-threaded Python is officially supported

30 points by subset 1y ago

poplarsol 1y ago
Is this still something that must be enabled at compile-time, or will it be supported via a runtime flag?
- TheChaplain 1y ago
  > 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.
- scott_w 1y ago
  > 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.
- xorvoid 1y ago
  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.
deleted 1y ago
[deleted]
mwpmaybe 1y ago
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?
- sco1 1y ago
  You can read the details in PEP 703: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- infamia 1y ago
  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.
- 12_throw_away 1y ago
  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-status-for-free-threaded-python/84319/123 https://discuss.python.org/t/pep-779-criteria-for-supported-...
sys_64738 1y ago
PI-thon.
12_throw_away 1y ago
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.

30 points by subset 1y ago

poplarsol 1y ago

Is this still something that must be enabled at compile-time, or will it be supported via a runtime flag?

TheChaplain 1y ago
> 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.
scott_w 1y ago
> 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.
xorvoid 1y ago
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.

deleted 1y ago

[deleted]

mwpmaybe 1y ago

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?

sco1 1y ago
You can read the details in PEP 703: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
infamia 1y ago
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.
12_throw_away 1y ago
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-status-for-free-threaded-python/84319/123 https://discuss.python.org/t/pep-779-criteria-for-supported-...

sys_64738 1y ago

PI-thon.

12_throw_away 1y ago

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.