You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We don't have a "nogil" image currently. For 3.13 we're using the default compilation settings, which AFAIK still results in the GIL. Unfortunately, compiling Python is pretty heavy, so expanding our current support matrix to include new "nogil" variants is also going to be a tough sell. 🙈
Reacted by Ouroboros Chrysopoeia, Sebastian Krause, Eric Carmichael, csd4ni3l, ChenCheng Jiang, Sara, Pedro Sacramento, Ivan Larin, Robyn, Fabien and 24 more
I'm not sure how you got there from what I said -- perhaps I can clarify: we do compile Python (currently ~42 times per architecture, in fact, and we support ~10 architectures where compilation is necessary), and it's very heavy to do so, and adding more variants would require us to do so even more times, so is not something we're willing to consider unless/until it is an officially recommended configuration (ideally the default configuration, but we'd be willing to consider an official statement along the lines of "everyone should try this out").
I agree that nogil is the future of Python, and there's nothing strange about the request. If I were completely opposed to the idea in general, I probably would've closed the issue already. It's more a matter of resourcing/prioritization, not desire/understanding. If the demand were actively higher, it would also be a lot easier to justify the added resources/maintenance spend -- the best way for folks to signal that is to react with 👍 on the top post in this thread.
To put that another way, my answer is more accurately "not yet", not "never".
If you'd like to help with the work, figuring out what changes are necessary to our current Dockerfiles would be a really useful first step.
Reacted by ydf, Tárliton Basso de Godoy, Mati O, Christopher Carroll Smith, nov12, Tuomo, Tomasz Czermiński, Kent Matsuura, zsdfcz, rhgsx and 6 more
An experimental JIT-enabled build would also be great to have
Reacted by Ouroboros Chrysopoeia, isolovey, Eric Carmichael, ChenCheng Jiang, Tárliton Basso de Godoy, Kyriakos Psarakis, 96bearli, Berkay YILDIZ, llfb, Christopher Carroll Smith and 14 more
Instead of prodiving a whole second set of "nogil" Docker images the free-threaded executable could also be part of the normal images just like it is done with the official Windows and macOS installers:
CPython now has experimental support for running in a free-threaded mode, with the global interpreter lock (GIL) disabled. This is an experimental feature and therefore is not enabled by default. The free-threaded mode requires a different executable, usually called python3.13t or python3.13t.exe. Pre-built binaries marked as free-threaded can be installed as part of the official Windows and macOS installers, or CPython can be built from source with the --disable-gil option.
Reacted by Ouroboros Chrysopoeia, hristoivanov, ydf, tkizm1, chai3, Eka Cahya Pratama, Andi Rady Kurniawan, Kai Londenberg, Christopher Carroll Smith, Julian Howes and 5 more
Python images without GIL and JIT enabled should be part of docker images. I have been using docker as a dev container and to experiment new versions of python. Thanks to all the work been done so far.
Reacted by Fabien, Andi Rady Kurniawan and Akaarir Mohamed
I'm a bit surprised that you're going out of your way to provide images for alpha versions of Python (if I'm reading https://hub.docker.com/_/python correctly, there are images for Python 3.14.0a2), but not for free-threaded builds which are an official feature of released Pythons. While these builds are still marked experimental, many Python packages have started using them to ensure they are free-threading compatible.
#947 (comment) is still an accurate representation of the current maintainer position
I would be willing to consider something like docker-library/tomcat#299 to have a place where folks can see/test Dockerfiles for this, but we cannot reasonably commit to producing official built images for it at this time.
Given the significant improvements to the free-threaded mode in Python 3.14, I would suggest prioritizing #1052 over providing a container for free-threaded 3.13.
@tianon You mentioned that you would consider this further if there was an official announcement encouraging the community to use the free-threaded build. Recently, PEP 779 was approved, moving the free-threaded build to Phase II (not experimental, but not default).
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 following a proper deprecation schedule. As approved by the 3.14 Release Manager Hugo van Kemenade, we recommend officially removing the “experimental” tag from the CPython free-threading build with the 3.14 beta 3 release.
Do I understand correctly that you're currently compiling Python over 400 times for the various architectures, and that supporting the free-threaded build would double this?
Do I understand correctly that you're currently compiling Python over 400 times for the various architectures, and that supporting the free-threaded build would double this?
Yes, that is correct in the abstract; in the specific, the various holes in the matrix mean it's closer to ~200 (232 at present, will increase when, for example, Trixie is released and #1042 means we add a bunch of notoriously slow/heavy-to-build riscv64 images, for example), but that's still a ton and it honestly kind of hurts to see it written out explicitly.
We could shrink the impact by doing "clever" things like only supporting "nogil" on a limited set of architectures, a limited set of base distributions, etc, but ultimately any choice we make there is definitely going to cause some amount of friction (both for us in maintaining and explaining the line, and for users who get to navigate the line).
We could also consider just including both in the default images, but I doubt that's going to be a popular choice either (and doesn't decrease the compilation burden, just obfuscates it). Ultimately it would be really interesting if this could be an entirely runtime determined value (or some way of having two binaries compiled concurrently and using linking cleverly so that they share most of the final binary size in shared libraries), but that's probably also a tall order.
(All of this is also not getting into the topic of what to call the tags/variants, because that's a whole separate rabbit hole as evidenced by that PEP using terms like "GIL-less", "free-threaded", and "with-GIL" and never using "nogil" to describe this. 🙈)
Ultimately it would be really interesting if this could be an entirely runtime determined value
Technically, it is possible to re-enable the GIL on the free-threaded build by setting the environment variable PYTHON_GIL=1. I don't know if it's intended for something like this. If you want, I could try getting in touch with the core developers working on the free-threaded build and see if they have any input.
Technically, it is possible to re-enable the GIL on the free-threaded build by setting the environment variable PYTHON_GIL=1. I don't know if it's intended for something like this.
It isn't, since re-enabling the GIL at runtime doesn't change the fact that that free-threaded build isn't ABI-compatible with the default build, hence no extension modules will work, wheel tags are different, etc.
a little slow for the single-threaded case than the gil python. I don't know how far they've come in covering this gap.
The single-threaded performance gap is down to the 5% - 10% range by now, which is within target.
(All of this is also not getting into the topic of what to call the tags/variants, because that's a whole separate rabbit hole as evidenced by that PEP using terms like "GIL-less", "free-threaded", and "with-GIL" and never using "nogil" to describe this
Activity
tianon commentedon Aug 12, 2024
We don't have a "nogil" image currently. For 3.13 we're using the default compilation settings, which AFAIK still results in the GIL. Unfortunately, compiling Python is pretty heavy, so expanding our current support matrix to include new "nogil" variants is also going to be a tough sell. 🙈
tianon commentedon Aug 12, 2024
I'm not sure how you got there from what I said -- perhaps I can clarify: we do compile Python (currently ~42 times per architecture, in fact, and we support ~10 architectures where compilation is necessary), and it's very heavy to do so, and adding more variants would require us to do so even more times, so is not something we're willing to consider unless/until it is an officially recommended configuration (ideally the default configuration, but we'd be willing to consider an official statement along the lines of "everyone should try this out").
tianon commentedon Aug 12, 2024
I agree that nogil is the future of Python, and there's nothing strange about the request. If I were completely opposed to the idea in general, I probably would've closed the issue already. It's more a matter of resourcing/prioritization, not desire/understanding. If the demand were actively higher, it would also be a lot easier to justify the added resources/maintenance spend -- the best way for folks to signal that is to react with 👍 on the top post in this thread.
To put that another way, my answer is more accurately "not yet", not "never".
If you'd like to help with the work, figuring out what changes are necessary to our current
Dockerfiles would be a really useful first step.ldeluigi commentedon Aug 19, 2024
An experimental JIT-enabled build would also be great to have
sekrause commentedon Aug 27, 2024
Instead of prodiving a whole second set of "nogil" Docker images the free-threaded executable could also be part of the normal images just like it is done with the official Windows and macOS installers:
https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython
So we would have
/usr/local/bin/python3.13tin every image and call this to use the free-threaded mode.Unfortunately that still means that all of Python has to be compiled twice.
sekrause commentedon Aug 27, 2024
The normal paths would still be there, but point to the normal GIL version. So if you don't adjust your tooling everything will be as before.
albertedwardson commentedon Sep 2, 2024
If anyone seeking for some basic image to play with, I've made one: https://github.com/abebus/free-threaded-python-docker-image
martin-budbee commentedon Oct 18, 2024
SDAravind commentedon Oct 21, 2024
Python images without GIL and JIT enabled should be part of docker images. I have been using docker as a dev container and to experiment new versions of python. Thanks to all the work been done so far.
msingh0101 commentedon Nov 22, 2024
pitrou commentedon Dec 18, 2024
I'm a bit surprised that you're going out of your way to provide images for alpha versions of Python (if I'm reading https://hub.docker.com/_/python correctly, there are images for Python 3.14.0a2), but not for free-threaded builds which are an official feature of released Pythons. While these builds are still marked experimental, many Python packages have started using them to ensure they are free-threading compatible.
For example in Apache Arrow we have our own image for CI until the official Python Docker images support free-threaded builds:
https://github.com/apache/arrow/blob/main/ci/docker/python-free-threaded-wheel-manylinux-test-imports.dockerfile
Many Python open source projects are probably using similar home-grown recipes due to lack of official Docker image availability.
albertedwardson commentedon Dec 18, 2024
@impredicative
is not possible to build (yet)
pitrou commentedon Dec 18, 2024
Those are unrelated, perhaps open a separate issue for JIT builds?
(but I'd argue that JIT builds are unimportant for now, as they don't provide tangible benefits)
rinarakaki commentedon Feb 21, 2025
Any update?
tianon commentedon Feb 21, 2025
#947 (comment) is still an accurate representation of the current maintainer position
I would be willing to consider something like docker-library/tomcat#299 to have a place where folks can see/test
Dockerfiles for this, but we cannot reasonably commit to producing official built images for it at this time.2 remaining items
hpkfft commentedon Jun 15, 2025
Given the significant improvements to the free-threaded mode in Python 3.14, I would suggest prioritizing #1052 over providing a container for free-threaded 3.13.
[-]Is there a 3.13 nogil container?[/-][+]Is there a nogil container?[/+]Harrison88 commentedon Jun 26, 2025
@tianon You mentioned that you would consider this further if there was an official announcement encouraging the community to use the free-threaded build. Recently, PEP 779 was approved, moving the free-threaded build to Phase II (not experimental, but not default).
The Steering Council announcement about the PEP acceptance specifically says:
Do I understand correctly that you're currently compiling Python over 400 times for the various architectures, and that supporting the free-threaded build would double this?
tianon commentedon Jun 26, 2025
Yes, that is correct in the abstract; in the specific, the various holes in the matrix mean it's closer to ~200 (232 at present, will increase when, for example, Trixie is released and #1042 means we add a bunch of notoriously slow/heavy-to-build riscv64 images, for example), but that's still a ton and it honestly kind of hurts to see it written out explicitly.
We could shrink the impact by doing "clever" things like only supporting "nogil" on a limited set of architectures, a limited set of base distributions, etc, but ultimately any choice we make there is definitely going to cause some amount of friction (both for us in maintaining and explaining the line, and for users who get to navigate the line).
We could also consider just including both in the default images, but I doubt that's going to be a popular choice either (and doesn't decrease the compilation burden, just obfuscates it). Ultimately it would be really interesting if this could be an entirely runtime determined value (or some way of having two binaries compiled concurrently and using linking cleverly so that they share most of the final binary size in shared libraries), but that's probably also a tall order.
(All of this is also not getting into the topic of what to call the tags/variants, because that's a whole separate rabbit hole as evidenced by that PEP using terms like "GIL-less", "free-threaded", and "with-GIL" and never using "nogil" to describe this. 🙈)
impredicative commentedon Jun 26, 2025
Is this the count for each version of Python, e.g. 3.13, or the sum across all supported versions?
tianon commentedon Jun 26, 2025
(I said this previously, which is where the 400 ballpark number came from)
3.13 is currently 40 and 3.14 is 38.
Harrison88 commentedon Jun 27, 2025
Technically, it is possible to re-enable the GIL on the free-threaded build by setting the environment variable
PYTHON_GIL=1. I don't know if it's intended for something like this. If you want, I could try getting in touch with the core developers working on the free-threaded build and see if they have any input.rgommers commentedon Jun 27, 2025
It isn't, since re-enabling the GIL at runtime doesn't change the fact that that free-threaded build isn't ABI-compatible with the default build, hence no extension modules will work, wheel tags are different, etc.
The single-threaded performance gap is down to the 5% - 10% range by now, which is within target.
freethreadingis the name to use, as per the explicit guidance from the Python Steering Council about package/installer names.tbiens commentedon Jul 31, 2025
It would be awesome if there was at least 1 option.
PS.
You folks are awesome, keep up the great work!
dandiep commentedon Sep 27, 2025
Any progress on this?
pitrou commentedon Sep 27, 2025
Uh??
JU4NP1X commentedon Oct 13, 2025
albertedwardson commentedon Oct 17, 2025
Also see: https://py-free-threading.github.io/installing-cpython/#use-containers
didier-viboo commentedon Oct 17, 2025