PythonCall.jl icon indicating copy to clipboard operation
PythonCall.jl copied to clipboard

Support free-threaded Python [3.14]

Open PallHaraldsson opened this issue 4 months ago • 2 comments

It's no longer marked experimental, as of 3.14 now in rc2.

https://py-free-threading.github.io/running-gil-disabled/

The free-threaded Python executable will always have a python3.13t alias (for Python 3.13); whether python, python3 and/or python3.13 point at the free-threaded executable depends on the installation method used (see the install guide for more details).

I believe it's off by default in 3.13, but should also be supportable there.

It's a question if JuliaCall should install and use those t versions. I'm not sure if it means any changes for JuliaCall, other than pointing to the right runtime.

PallHaraldsson avatar Aug 18 '25 15:08 PallHaraldsson

Cool, I didn't know it was non-experimental now.

It would certainly make PythonCall simpler if it could assume there was no GIL. However since the GIL gets re-enabled if you load a module which requires the GIL then for now at least we need to keep the GIL handling.

If the ABI is the same for free-threaded and ordinary python then PythonCall should just work with it.

Is a free-threaded build available on conda-forge or similar?

It's possible we could have a bit of special functionality. For instance we could have a way to specify we want a free-threaded build. And we could have a preference which forces free-threaded mode (PYTHON_GIL=0) and turns our GIL handling into no-ops.

cjdoris avatar Aug 18 '25 15:08 cjdoris

To answer my own question, yes there are some meta-packages to specify which flavour of python to use.

https://anaconda.org/conda-forge/python-freethreading

So someone can already just add python-freethreading to their CondaPkg.toml to get such a build.

Would be good to run the test suite on it.

cjdoris avatar Aug 18 '25 15:08 cjdoris