Hi @FFY00 is there anything we can do to get this merged please? I just stumbled on this bug and I noticed the PR already exists to fix it (thanks!) but since it has been sitting here for 12 months, I figured it might have been forgotten about.

This PR is stale because it has been open for 30 days with no activity.

The POSIX half is now redundant: on current main, invoking venv as a renamed interpreter already creates the host name — python3.99 -m venv produces bin/python3.99 alongside python/python3/python3.X. So that hunk adds nothing on POSIX (and it targets pre-rebase code — the PR is conflicting).

The remaining gap is Windows. Since the free-threading rewrite, setup_python on Windows emits python.exe/pythonw.exe and the python3.Xt.exe variants but no bare python3.exe and no host name (init.py L351-393). That's the canonical python3.exe -m venv → WinError 2 from the issue, and this PR adds only the current invocation name, so python3.exe is still missing when venv is launched as python.exe or via py.

For reference, virtualenv emits a fixed set of names rather than the invocation name: POSIX python, python3, python3.X, python3.Xt, <host>; on Windows it also creates python3.exe and the pythonw* group, keyed on the resolved base (interpreter.system_executable) and copying the launcher (cpython/common.py L36-43). A fixed set that always includes python3.exe would cover the Windows case. Two smaller things: using sys._base_executable (what the rest of setup_python uses) rather than sys.executable, and the NEWS file references gh-129382 instead of gh-87915.