Post History

<section class="notice is-warning">

This answer assumes only installations of the reference "CPython" implementation, as provided by the official website at https://www.python.org. Other installations - such as those provided by the Microsoft Store or by Anaconda, or alternate implementations such as PyPy or IronPython - may introduce additional complications.
</section>

## Platform-agnostic information

Generally, every installation of Python has its own Python executable - i.e., `python` on Linux and Mac, or `python.exe` on Windows. ([On Mac, using Python 3.8 or earlier](https://docs.python.org/3/using/mac.html#running-scripts-with-a-gui), it may be necessary to use `pythonw` for graphical programs; similarly, `pythonw.exe` is provided on Windows to allow launching graphical programs without needing an associated terminal window.) So on the most basic level, the Python installation is chosen by simply choosing the Python executable.

**You can always choose which Python to use if you know the path to the executable, by specifying that path directly**.

However, this is often awkward, so the Python installers try to make it easier to choose the Python you want. This is done in platform-specific ways.

## Linux and Mac

Python follows standard UNIX conventions by putting the actual `python` executable directly in `/usr/bin` (or another similar folder, such as `/usr/local/bin`, if you build from source and explicitly configure the installation that way)[^1]. Since that path is always in the `PATH` environment variable, simply using `python` at the command line will find a Python installation as long as there is one.[^2]

Of course, this naturally raises the question of what happens if we try to install more than one Python version. The simple answer: **`python` is actually a symlink to one specific Python executable**; the actual executables will be named according to the major and minor version number: thus, `python27` for the [now end-of-life and unsupported](https://www.python.org/doc/sunset-python-2/) Python 2.7; `python312` for the Python 3.12; etc. **We can generally use these names directly on the command line, to choose the Python minor version, and thus the associated installation of Python.**

Depending on the system configuration, there may also be `python2` and/or `python3` symlinks that will refer to a specific 2.x or 3.x installation respectively. (`python2`, if present, should normally mean a Python 2.7 installation, except on *very* old legacy systems.)

<section class="notice is-danger">

Generally, if Python came with a Linux system, the `/usr/bin/python` symlink will refer to that Python, and *should not be changed except by means approved by the distro* - as important system scripts could rely on `python` referring to that specific installation.
</section>

## Windows

Windows generally organizes programs differently. It doesn't offer a separate folder for application-specific "libraries" (i.e. `/usr/lib` equivalent), and doesn't put system-wide installed executables side-by-side. Instead, generally each application gets its own sub-folder within `C:\Program Files` (or a similarly named location); and Python respects this convention.[^3] It's also probably more common on Windows systems to see Python installed "only for this user", which doesn't require administrator privileges.[^4]

Windows' organization scheme is problematic for command-line use of programs (including Python) because they can only be found directly in folders named in the `PATH` - subdirectories are *not* searched. 

<section class="notice is-warning">

As a result, **the version-specific executables can only be found automatically at the command line, if their containing folder is added to the `PATH`** - which has to be chosen explicitly in the installer. **This is disabled by default**, in part because it would pollute the `PATH` - the [length of this environment variable is limited](https://devblogs.microsoft.com/oldnewthing/20100203-00/?p=15083), and there can be bad consequences for overflowing that length.

Worse, there are actually multiple separate `python.exe`s, and **the version that gets run would depend on the *order of the `PATH` entries*** - which is much less convenient than pointing a symlink directly at the desired target. And, of course, this only considers versions whose folders were added to the `PATH` at all.
</section>

However, each installation provides separate executables (wrappers around the main DLL) following a similar naming scheme. So if one is willing to pollute the `PATH` in this way, the same sort of version-selection logic can be used on Windows as on Linux or Mac.

## The [Python Launcher for Windows](https://docs.python.org/3/using/windows.html#python-launcher-for-windows)

<section class="notice is-success">

To avoid these `PATH` issues, on Windows systems, it is strongly recommended to use the provided "launcher" program instead.
</section>

This is a separate application named `py.exe` which is installed directly in `C:\Windows` (so it's always on the `PATH`) and which chooses a Python installation for you. Installed versions of Python automatically register themselves with the launcher, and running `py` at the command line will choose an appropriate Python version - the most recent Python by default (even if it wasn't the most recently *installed*); or a version explicitly specified on the command line; or a version specified by the Python code itself.

Note that last part carefully: while Windows has no concept of a "shebang line" natively, the launcher emulates them for Python scripts.

The Python launcher for Windows offers quite a few customization options; please see the link in the section title for full documentation.

## Patch versions, redundant installations etc.

The above schemes aren't designed to support more than one patch version of a given Python minor version; or multiple redundant installations of the same version. Indeed, on Windows you simply won't be able to install multiple patch versions of the same Python version, except perhaps if one is installed for all users and the other is user-specific. (On Linux, of course, you can always compile whatever versions you like from source; but you're on your own for "installing" them and keeping track of where they are.)

But to reiterate: if you have a separately built version of Python that is not explicitly "installed" but is still usable, you can still always choose to use it by explicitly specifying the path to the specific Python executable.

**If you use virtual environments, therefore, you can still specify the path to the executable** (whether a symlink or a separate file) created for that virtual environment. **Alternately, you can *activate* the virtual environment** by using the activation script it provided. This works by temporarily modifying `PATH` (and decorating the terminal prompt as a reminder), and setting up a deactivation command that will undo the changes. *There is otherwise nothing special* about activating a virtual environment (unless of course your script somehow depends on that change to `PATH`).

[^1]: It's also possible to set up per-user installations on Linux, which might go in a folder like `~/.local/bin`. However, this doesn't really meaningfully impact on the advice given here.

[^2]: Almost all Linux distros will include some version of Python. [Certain MacOS versions included](https://docs.python.org/3/using/mac.html#getting-and-installing-python) Python 2.7; but of course that is out of date now, and so are those MacOS versions.

[^3]: Older Python versions used to install directly to the drive root - i.e. `C:\PythonXY`. This may have been to avoid problems caused by paths with spaces in them. However, this appears to have changed in Python 3.5 with the [introduction of a new installer](https://docs.python.org/3/whatsnew/3.5.html#summary-release-highlights).

[^4]: [Current installers default](https://docs.python.org/3.13/using/windows.html#installation-steps) to a user-specific installation, and extra steps are needed to install "for all users", in addition to administrator privileges.