Introduction

Running multiple Python versions on Windows is a normal requirement when different projects target different runtimes. The cleanest setup is to install each version side by side, use the Windows Python launcher to select the version you want, and then create a separate virtual environment per project.

Install Versions Side by Side

Windows can host several Python versions at once. The important part is not to rely on one global python.exe on PATH for everything.

For example, you might install Python 3.10, 3.11, and 3.12 from the official installers. During installation, let each one install its own files normally. The Windows Python launcher, named py, is what makes this manageable.

After installation, open PowerShell or Command Prompt and inspect what the launcher sees:

py -0p

That command lists installed Python runtimes and their paths. It is one of the most useful checks on Windows because it tells you exactly which interpreters the launcher can target.

Use the Python Launcher Instead of Guessing

The main advantage of Windows is the py launcher. Rather than hoping python points to the right interpreter, you can ask for the exact version:

py -3.11 --version
py -3.12 --version

You can also run scripts with a selected version:

py -3.10 script.py
py -3.12 script.py

That keeps version choice explicit and avoids many PATH problems.

If you type just:

python --version

the answer depends on your current PATH, app execution aliases, and other local settings. That is why py is usually more reliable for multi-version Windows setups.

Create One Virtual Environment Per Project

Once you have multiple interpreters installed, create a virtual environment with the exact interpreter the project needs.

For a Python 3.11 project:

py -3.11 -m venv .venv
.\.venv\Scripts\activate
python --version

For a Python 3.12 project in another folder:

py -3.12 -m venv .venv
.\.venv\Scripts\activate
python --version

This is the key workflow. You are not switching the whole machine from one version to another. You are choosing the interpreter per environment and per project.

Keep Project Dependencies Isolated

After activating the environment, install packages normally:

pip install requests
pip freeze > requirements.txt

Each environment keeps its own packages. That prevents one project's dependencies from contaminating another project's runtime.

If you use tools such as tox, nox, or uv, the same underlying principle still applies: the project should declare which interpreter it needs, and you should let the tool target that exact interpreter rather than a random global default.

A Practical Workflow

Suppose you maintain one older app on Python 3.10 and one newer app on Python 3.12.

Project A:

1cd C:\work\legacy-app
2py -3.10 -m venv .venv
3.\.venv\Scripts\activate
4pip install -r requirements.txt

Project B:

1cd C:\work\new-app
2py -3.12 -m venv .venv
3.\.venv\Scripts\activate
4pip install -r requirements.txt

That is usually enough. There is no need to keep uninstalling and reinstalling Python globally.

When PATH Still Matters

PATH is not irrelevant, but it should not be your main selector. If you do want python to resolve predictably in a shell, activate the virtual environment first. Inside the environment, python points to the environment's interpreter.

That gives you both convenience and correctness:

• 'py chooses the interpreter at environment creation time'
• activation makes python resolve to that chosen interpreter afterward

Common Pitfalls

• Depending on a single global python command instead of the Windows py launcher.
• Installing multiple versions but not checking them with py -0p.
• Reusing one virtual environment after upgrading Python instead of recreating it with the correct interpreter.
• Mixing global packages with project environments.
• Forgetting that an activated virtual environment changes which python and pip commands you are using.

Summary

• On Windows, install multiple Python versions side by side and manage them with the py launcher.
• Use py -0p to see available interpreters and py -3.x to select one explicitly.
• Create a separate virtual environment for each project with the correct Python version.
• Activate the environment before running python or pip.
• Avoid using PATH as your main version-switching strategy when the launcher and virtual environments already solve the problem cleanly.