Build changes for Windows free-threaded builds

[zooba]

We should use a different $(IntDir) and $(OutDir) for free threaded builds so that it's faster to switch between them and so they can be built in parallel.

The output filename should be python{major}.{minor}t.exe and python{major}{minor}t.dll. Debug builds are python{major}.{minor}t_d.exe and python{major}{minor}t_d.dll.

The ABI tag becomes .cp{major}{minor}t-{plat}

All stdlib .pyd files get an ABI tag.

The python.bat is updated as normal (overwriting the last yesgil build).

The installer should not include a python.exe, to avoid causing PATH conflicts, but Nuget, embeddable and Store packages should include a copy/alias.

PEP 514 registration (a.k.a. sys.winver) should use {major}.{minor}t-{plat}.

Tests that rely on the executable name should use sys.executable wherever possible, and hopefully there's a support variable already for the rest.

All of these only take effect when $(DisableGil) == 'true' (which is set by build.bat --disable-gil, but the build variable is canonical).

Linked PRs

• gh-112984 Update Windows build for free-threaded builds #113129
• gh-112984: Fix test_ctypes.test_loading.test_load_dll_with_flags when directory name includes a dot #114217
• gh-112984: Fix link error on free-threaded Windows build #114455

[zooba]

Deliberately not updating sys.version, sys.thread_info or the opening prompt of the REPL in this PR, because those affect all platforms and other people will want to argue about them.

[zooba]

So I've added an installer option in this PR

Normal first page:

Where you go after clicking "Customize":

The page with the new option (last checkbox):

It's labelled "Download" because the files will be on python.org and downloaded on demand, so if you don't have internet access you won't get them. The installer already has a /layout option to pre-download all its optional components, so it's nothing new here.

After install, there's a python3.13t.exe and pythonw3.13t.exe installed alongside the usual python.exe/pythonw.exe. Right now, they're already registered as normal, which means py.exe -3.13t will select it while py.exe -3.13 gets the usual version. There's also a "Python 3.13 (64-bit, free-threaded)" shortcut added to the start menu.

Unfortunately, py.exe -3 will select the free-threaded one, which I don't like but don't really have a great way to solve it - the easiest way is to make it so you need something like py.exe -V:PythonFreeThreaded/3.13 to get the free-threaded build, which has the advantage that py.exe -V:PythonFreeThreaded/ will get the latest free-threaded build available, but a disadvantage is that shebang parsing won't be able to select it (without writing special case code in the launcher, which I'd rather not do if it can be avoided). On balance, I think it's probably best to change the company name to PythonFreeThreaded or something like that - open to suggestions!

Right now, venv will create python3.13t.exe in the new environment. I'm tempted to say it should create python.exe instead, as that will make it easier to use. It probably requires more significant changes to venv though, so I'd rather do it later. Different venvlauncher implementations are needed because they "know" the name of the real executable will be, so we already do a sneaky rename. (Possibly that's being done wrong in the current PR...)

I haven't yet created a Nuget package or embeddable distro for the files. I'm leaning toward python-freethreaded and pythonarm64-freethreaded packages on Nuget. This will really help out people running on CI, as they'll be able to easily get a set of binaries independent from what the CI image contains and without having to run an installer as part of their job. We could also just put a zip file of the binaries on python.org, but I fear it would clutter the list of downloads (which is already considered cluttered). No separate embeddable distro at this stage, people can build it easily enough if they want it.

[zooba]

Today's updates:

• fixed venv (possibly more broadly than necessary to avoid having too many special cases for this... @vsajip, I'd appreciate a review)
• updated the installer/layout tools
• started release builds PR Implement free-threaded build for Windows release release-tools#81

[vsajip]

There's quite a lot of venv-related change - is there any discussion or design documentation anywhere? For example, about the venvlauncher executable - what is the need/rationale for it, as it appears to be new in this PR?

[zooba]

The venvlauncher.c is just launcher.c boiled down to just the venv parts, and none of the py.exe parts. The only change is that the executable embeds the expected Python executable name at compile time, as we can't just assume it'll be python[_d].exe anymore.

The changes to venv\__init__.py should just streamline things for Windows. We need to more carefully pick the right redirector, and we can't rely on the name being python.exe anymore, and trying to handle the symlink->copy fallback per-file was already pretty rough as we aren't copying the regular executables.

The design is the same as it was before, it's mainly just refactoring how we get there.

[encukou]

Do you plan to provide freethreaded debug (td) binaries?
That does start a combinatorial explosion of builds, but I figure that people will need all the debugger help they can get. (And they'll want to run benchmarks so building only dt isn't appropriate.)