venvs created using python3.15t.exe from Python3.15.0b1 create scripts for a GIL-enabled interpreter

[ngoldbaum]

Bug report

Bug description:

Using 3.15t installed with the MSI installer, but it happens with the pymanager build as well:

PS C:\Users\goldbaum> python3.15t.exe -VV
Python 3.15.0b1 free-threading build (tags/v3.15.0b1:f31a89b, May  7 2026, 13:47:35) [MSC v.1950 64 bit (AMD64)]
PS C:\Users\goldbaum> (Get-Command python3.15t.exe).path
C:\Users\goldbaum\AppData\Local\Programs\Python\Python315\python3.15t.exe
PS C:\Users\goldbaum> rm -r .venv
PS C:\Users\goldbaum> python3.15t.exe -m venv .venv
PS C:\Users\goldbaum> .\.venv\Scripts\python.exe -VV
Python 3.15.0b1 (tags/v3.15.0b1:f31a89b, May  7 2026, 13:53:53) [MSC v.1950 64 bit (AMD64)]
PS C:\Users\goldbaum> .\.venv\Scripts\python3.15t.exe -VV
Python 3.15.0b1 (tags/v3.15.0b1:f31a89b, May  7 2026, 13:53:53) [MSC v.1950 64 bit (AMD64)]

Doing the same thing with Python 3.14.5 from the MSI installer:

PS C:\Users\goldbaum> python3.14t.exe -VV
Python 3.14.5 free-threading build (tags/v3.14.5:5607950, May 10 2026, 10:44:56) [MSC v.1944 64 bit (AMD64)]
PS C:\Users\goldbaum> (Get-Command python3.14t.exe).path
C:\Users\goldbaum\AppData\Local\Programs\Python\Python314\python3.14t.exe
PS C:\Users\goldbaum> rm -r .venv
PS C:\Users\goldbaum> python3.14t -m venv .venv
PS C:\Users\goldbaum> .\.venv\Scripts\python.exe -VV
Python 3.14.5 free-threading build (tags/v3.14.5:5607950, May 10 2026, 10:44:56) [MSC v.1944 64 bit (AMD64)]
PS C:\Users\goldbaum> .\.venv\Scripts\python3.14t.exe -VV
Python 3.14.5 free-threading build (tags/v3.14.5:5607950, May 10 2026, 10:44:56) [MSC v.1944 64 bit (AMD64)]

Ping @zooba @zware @chris-eibl

CPython versions tested on:

3.15

Operating systems tested on:

Windows

[chris-eibl]

I am afk until mid next week, will have a look then.

[sergey-miryanov]

Could you clarify what path pyvenv.cfg is pointing to?

[ngoldbaum]

Could you clarify what path pyvenv.cfg is pointing to?

PS C:\Users\goldbaum> rm -r .\.venv\
PS C:\Users\goldbaum> python3.15t.exe -m venv .venv
PS C:\Users\goldbaum> cat .\.venv\pyvenv.cfg
home = C:\Users\goldbaum\AppData\Local\Programs\Python\Python315
include-system-site-packages = false
version = 3.15.0
executable = C:\Users\goldbaum\AppData\Local\Programs\Python\Python315\python3.15t.exe
command = C:\Users\goldbaum\AppData\Local\Programs\Python\Python315\python3.15t.exe -m venv C:\Users\goldbaum\.venv
PS C:\Users\goldbaum> .\.venv\Scripts\python.exe -VV
Python 3.15.0b1 (tags/v3.15.0b1:f31a89b, May  7 2026, 13:53:53) [MSC v.1950 64 bit (AMD64)]
PS C:\Users\goldbaum> C:\Users\goldbaum\AppData\Local\Programs\Python\Python315\python3.15t.exe -VV
Python 3.15.0b1 free-threading build (tags/v3.15.0b1:f31a89b, May  7 2026, 13:47:35) [MSC v.1950 64 bit (AMD64)]

[ngoldbaum]

Claude Opus 4.7 points at fallout from 10f950c. The executable name is baked into venvlaunchert.exe but the build configuration now bakes in python.exe.

[zooba]

Yeah, obviously when making the build always generate python.exe (since the free-threaded build output now goes to another directory) I missed that the property is also embedded into the venv redirector.

It's also broken on PyManager because we don't actually create a python.exe there for free-threaded builds (that was the intent, not sure why it failed, probably another change after I tried it).

So as with the abi3-compat directory, I think we're looking at a 3.15-only flag to put the versioned name into the venvlauncher executables, and a fix to make sure installs other than the MSI will have a python.exe even for free-threaded builds (since they're split up by sys.prefix so the name won't collide).