This is practically my most recent proposal (not in the PEP text yet), with the one difference that python.exe
will run your selected default version at any time (or one selected by a script shebang), rather than continuing to run the one that was originally bundled. This is important so that when we release a new version of Python, users don’t have to update the installer just to change what the default python
launches.
No, the compatibility break is for users who do things like running scripts to download the installer from the website and run it with particular options. Not users of the final installed Python.
If the VIRTUALENV
environment variable is set then it runs that instead of searching for an install. Personally I never use py
in a venv - I always just use python
- so I’m not sure how well it works. But Paul lives by this feature, so it clearly has a place
Because a good tool has a home for all its commands, and py
is a shortcut to one of those commands. (Compare with uv run
and uvx
.)
We would churn again for something that big. I’m more concerned about having had to churn people in order to support running the installer as a service account, or churning people to put python3
on PATH
. Stuff that’s very unique to an install on Windows, and hasn’t been possible under the old system.
The advantage is faster installs, fewer security vulnerabilities in the installer, more flexible installation options, access to more versions, better scriptability of (per-user) installs. The cost is churn to installation steps, loss of per-machine installs, and loss of automatic PATH updates (but with py
, python
and python3
no longer requiring them).