This is a good point. Will both gil and nogil Windows builds of 3.13 be available, and installable simultaneously? If the answer is “no”, then I suspect nogil will get limited testing on Windows, which would be a shame. The same question applies for Mac builds.
Also, while it’s not a core Python concern as such, will distributions such as Fedora, Ubuntu, Homebrew, the Windows Store and conda ship both gil and nogil builds?
I guess my point is, what will the overall user experience be for the average Python user, who doesn’t build their own Python interpreter (except maybe in some “packaged” sense like pyenv)? How will they say "I want to run Python 3.13 without the GIL? Will the Python launcher for Windows grow a --nogil option, for instance?
This links back to the packaging question, because how easy it is for users to try out nogil builds, and how easy it is for a user to select between nogil and gil, will strongly affect how much demand there is for nogil builds, and hence how much pressure there will be on package maintainers to provide nogil-compatible wheels in the first place.
I’d like gil and nogil Windows builds of 3.13 available and installable simultaneously, and I think that’s achievable, but I’d like to keep this discussion here focused on ABI issues, particularly the stable ABI. I don’t think the choices here will affect available Python installers.
The gil version of python executable is “python3”.
What is the name of the nogil executable? “python-nogil3”, “python-nogil3.13” etc?
This will be needed when setting a shebang line and best its not left to each distro to pick incompatible names.
The interpreter executable name is not part of the ABI.
Regardless, we don’t want any OS distros to ship a 3.13 free threading build as an OS package with something in a default $PATH. It is still experimental in this timeframe.
A #! line can happily point to a different installation location of an /opt/py/experimental/free-threading/bin/python binary.
We cannot control distros. They all make their own mistakes. At best I suspect all we can do is just state our expectation up front. Those who go against that know they’re doing a thing we deem wrong and can face social pressure to not be that way.
Why? Long term assume free threaded python is successful exiting experimental phase as we presumably all want. Nobody wants to see an even harder to type interpreter name left lying around as the actual interpreter. when you’re getting down to a full version X.YY specified name maybe it doesn’t matter so much as that isn’t intended to be general, but you’d never want to see a generic unversioned python3-with-blue-sparkles-without-goats-or-wombats unversioned executable.
The existence of things like yum^Wapt install python-is-python3-with-blue-sparkles-without-goats-or-wombats is an anti-pattern.
In effect this defers any potential install naming decision until 3.14 or later once we’ve got some practical knowledge of how things are working out - we’ll presumably know better at that time if there’s a need for parallel installs. It’s okay for some things like this to be decided later, in effect that is why PEP-703 has an Open Issues section not fully specifying this area today.
Fedora packages python3-debug (which is very useful for finding bugs!), and I assume we’ll want python3.13-nogil to for all the hype. We do want users will want to test the experimental build without hassle, and /opt is not really an option for an OS-provided package.
The argument against python3-nogil and python-nogil sounds good.
What are your thoughts on printing a colourful warning on interactive mode startup?
I agree with this. I would like to be able to write scripts with #!/usr/bin/env python3.13-nogil (or something like that) in order to get the free threaded build without needing to hard-code a long and probably non-intuitive path (which on Windows is also user-specific).
On Windows, @steve.dower’s proposal for the launcher to support py -V:3.13-nogil works for the REPL, but doesn’t give a good solution for scripts.
It should actually work on Windows at least, where a #!/usr/bin/env python... shebang is first interpreted as py -V:... unless there’s a matching executable on PATH.[1]
I might be misremembering the exact behaviour here, there were bugs reports recently about things happening in unexpected order, and I wrote a change but don’t remember if it’s merged. ↩︎
Channelling/re-connecting another fork of discussions - Lets discourage people from calling executables or packages “nogil” for the sake of our users per Nogil installers on Windows - #3 by gpshead.
This is literal bikeshed repl painting, I like it. I vote rainbow!
I’ll leave naming details to others (I like nogil, which is out). But:
I expect there will be many issues that need debugging, but people will also want to compare performance with the default build. A fourth *-freethreading-debug build seems like the best way to serve users :/
