venv.EnvBuilder creates inconsistent venv depending on the name of the Python executable

Bug report

Bug description:

Given the below create-venv.py script and several Python 3 installed in the classpath:

import sys
import venv


if __name__ == "__main__":
    venv.EnvBuilder().create(sys.argv[1])

Let’s create various venvs:

for VERSION in 3.9 3.11 3.12; do
  python$VERSION create-venv.py $VERSION-venv
  for EXEC in python python3 python$VERSION; do
    $VERSION-venv/bin/$EXEC create-venv.py $VERSION-$EXEC-venv
  done
done

And now, let’s check them:

for PYTHON in *-venv/bin/python; do
  echo "$PYTHON: $($PYTHON --version)"
done

The above loop outputs:

3.11-python3.11-venv/bin/python: Python 3.11.7
3.11-python3-venv/bin/python: Python 3.9.14
3.11-python-venv/bin/python: Python 3.9.14
3.11-venv/bin/python: Python 3.11.7
3.12-python3.12-venv/bin/python: Python 3.12.1
3.12-python3-venv/bin/python: Python 3.9.14
3.12-python-venv/bin/python: Python 3.9.14
3.12-venv/bin/python: Python 3.12.1
3.9-python3.9-venv/bin/python: Python 3.9.14
3.9-python3-venv/bin/python: Python 3.9.14
3.9-python-venv/bin/python: Python 3.9.14
3.9-venv/bin/python: Python 3.9.14

As the reader can see, Python venv’s created by python or python3 executable of a Python venv will not use the Python of this venv, and instead will use the system’s default Python (3.9 in my case).

CPython versions tested on:

3.11, 3.12

Operating systems tested on:

Oracle Linux 9 and 10

Comienza con el script proporcionado create-venv.py y el punto de entrada venv.EnvBuilder; después, ejecuta el bucle de shell con varios nombres de ejecutables de Python para reproducir la selección inconsistente del intérprete. Sigue cómo se registra el ejecutable utilizado para invocar EnvBuilder y cómo se usa al crear cada entorno; la tarea estará terminada cuando python, python3 y los ejecutables con versión dentro de una venv creen de forma coherente entornos utilizando el intérprete de esa venv.