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

Inizia con lo script fornito create-venv.py e il punto di ingresso venv.EnvBuilder, quindi esegui il ciclo shell con più nomi di eseguibili Python per riprodurre la selezione incoerente dell’interprete. Traccia il modo in cui l’eseguibile usato per invocare EnvBuilder viene registrato e utilizzato durante la creazione di ciascun ambiente; il lavoro è completato quando python, python3 e gli eseguibili con versione all’interno di una venv creano in modo coerente ambienti usando l’interprete di quella venv.