Naming the Python binary when `--disable-gil` is set

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.

1 Like

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.

Is the shebang part of the ABI?


Exactly what I was trying to get at, Other Barry :smiley:

[personal reply hat, non-SC-voice]

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.

cc @hroncok

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?

1 Like

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]

  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. ↩︎

1 Like

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! :stuck_out_tongue:


I recommend calling it python-multicore :slight_smile:

1 Like

In Fedora, I was able to build a third build of Python 3.13.0a1 with --disable-gil (the first two being the optimized and debug build with GIL).

The package contains:

  • /usr/bin/python3.13t
  • /usr/lib64/ and /usr/lib64/
  • /usr/lib64/python3.13/lib-dynload/*

The questions I have:

  • Should the RPM package be called python3.13-free-threading or python3.13-freethreading or something else?
  • Should there be /usr/bin/python3.13-free-threading at all? Isn’t /usr/bin/python3.13t good enough?
  • Should we package a debug build of this as well (as a 4th option)? And if so, what should that be called, python3.13-free-threading-debug?

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 :‍/

I would name then with the version on the end - possible names:

  • python-t-3.13
  • python-ft-3.13
  • python-freethreading-3.13
  • python-free-threading-3.13

I will certainly need a debug build on Fedora to work on PyCXX and PySVN.

Sticking the version at the end would be highly unusual.

Anyway, I now have:

  • python3.13
  • python3.13-debug
  • python3.13-freethreading
  • python3.13-freethreading-debug

(I didn’t like the dash in free-threading, and I consider t of ft to be quite cryptic.)

I also decided not to add any executable names except the ones with the ABI flags, at least not yet.

If we do this, perhaps we should block the freethreading name on PyPI?

1 Like

The freethreading and free-threading names are now blocking on


And the Fedora pull request has been rebased and dusted off.

1 Like