Installing Python and Setting Up Your Environment

A Python installation is more than a single program on disk. It is a small ecosystem: the CPython interpreter that actually runs your code, a standard library of ready-to-use modules, the pip package manager for third-party libraries, and a venv module that lets every project have its own isolated set of packages. Getting these pieces installed correctly on the first try saves hours of confusion later when imports fail for reasons that have nothing to do with your code.

Python is released on a steady yearly cadence. The supported lines today are Python 3.10, 3.11, 3.12 and 3.13. Unless a specific library requires otherwise, choose the most recent version that is still getting bug-fixes. The official installers from python.org are the most predictable source on Windows and macOS; Linux users generally install from the distribution package manager (apt, dnf, pacman) or from pyenv when multiple versions are needed side by side.

The single most important choice on Windows is the "Add python.exe to PATH" checkbox in the installer. Ticking it means you can type python and pip in any terminal instead of hunting for their full file paths. On macOS the installer registers python3 and pip3 next to the system Python; on Linux they are usually already on the PATH. If you ever see the message "command not found" after installation, the PATH step is almost always the culprit.

Once the interpreter is installed, the habit that prevents almost all "it works on my machine" bugs is creating a virtual environment per project. A virtual environment is a small folder that contains a fresh copy of python and pip; anything installed after activating it stays inside that folder and never touches the system Python. This means two projects can require different versions of the same library without interfering, and you can delete the folder to reset the project cleanly.

Finally, pick one editor and learn its Python workflow. Visual Studio Code, PyCharm Community and the built-in IDLE all run the same interpreter in the background; what differs is how they help you edit, debug and format code. The rest of this course assumes a working python command, a working pip, and the ability to activate a virtual environment in your terminal. The sections below walk through verifying each of those pieces.

Verifying the interpreter and pip

After installation, open a new terminal and check that python --version (Windows) or python3 --version (macOS/Linux) prints the version you installed. Run python -c "import sys; print(sys.executable)" to see which interpreter actually answered — useful when you have several versions on the PATH. Then run pip --version (or pip3 --version); pip should report the same Python version it is tied to. If it reports a different version than python --version, one of them is coming from somewhere else on the PATH and you should fix the order before going further.

If pip is missing entirely, the command python -m ensurepip --upgrade installs it from the standard library. In fact, running tools through python -m (for example python -m pip) is a reliable habit: it always runs the tool that matches the interpreter you invoked, bypassing any PATH confusion.

Creating and using a virtual environment

Inside the folder where you keep a project, run python -m venv .venv. This creates a .venv subfolder with its own interpreter and pip. Activate it with .venv\Scripts\activate on Windows (PowerShell: .venv\Scripts\Activate.ps1) or source .venv/bin/activate on macOS and Linux. Your prompt gains a (.venv) prefix to remind you the environment is active.

Once active, pip install <package> writes to .venv instead of the system Python. Record the dependencies with pip freeze > requirements.txt so collaborators can recreate the same environment with pip install -r requirements.txt. When you are done, deactivate returns the terminal to the system Python. Deleting the .venv folder resets the project completely — no registry entries, no leftover config.

These are the core commands you will use for Installing Python and Setting Up Your Environment. Skim the table before running the code example, and click any name to open the official documentation.

Installing Python and Setting Up Your Environment code example

The script below verifies the interpreter, the active environment, and the pip version in a way you can paste into any fresh setup to confirm everything works.

# Lesson: Installing Python and Setting Up Your Environment
# Goal: confirm that the interpreter, its virtual environment, and pip are
# all reporting consistent information. Run with:  python check_setup.py
import os
import platform
import sys
from importlib import metadata


MIN_SUPPORTED = (3, 10)


def check_python_version() -> tuple[int, int, int]:
    '''Raise if the running interpreter is older than MIN_SUPPORTED.'''
    major, minor, micro = sys.version_info[:3]
    if (major, minor) < MIN_SUPPORTED:
        raise RuntimeError(
            f"Python {major}.{minor} is too old; need >= {MIN_SUPPORTED[0]}.{MIN_SUPPORTED[1]}"
        )
    return major, minor, micro


def in_virtualenv() -> bool:
    '''True if sys.prefix points inside a venv created with python -m venv.'''
    return sys.prefix != getattr(sys, "base_prefix", sys.prefix)


def pip_version() -> str:
    '''Read pip's version from importlib.metadata, not from the command line.'''
    try:
        return metadata.version("pip")
    except metadata.PackageNotFoundError:
        return "pip not installed"


# --- main script ---------------------------------------------------------
version = check_python_version()
print(f"python:   {'.'.join(map(str, version))} ({platform.python_implementation()})")
print(f"venv:     {'active' if in_virtualenv() else 'system interpreter'}")
print(f"prefix:   {sys.prefix}")
print(f"pip:      {pip_version()}")
print(f"platform: {platform.platform()}")
print(f"cwd:      {os.getcwd()}")

Read the script top-down before running it so each check earns its keep:

1) `check_python_version()` fails fast if the interpreter is too old.
2) `in_virtualenv()` compares sys.prefix to sys.base_prefix; they differ only inside a venv.
3) `pip_version()` uses importlib.metadata so no subprocess is required.
4) The final prints give one line per fact, easy to paste into a bug report.

Try both snippets after the main script succeeds to stretch the concept.

# Example A: confirm the exact interpreter answering imports
import sys
print("running:", sys.executable)
print("search path (first 3):", sys.path[:3])

# Example B: install a package into the active environment and verify it
#   (run these as shell commands, not Python)
#   pip install requests
#   python -c "import requests; print(requests.__version__)"
# If Example B fails with ModuleNotFoundError, the venv is not active in the
# shell where you ran pip. Re-activate and retry.

Run these assertions inside the same interpreter to catch a broken setup early.

assert sys.version_info >= (3, 10), "upgrade Python before continuing"
assert pip_version() != "pip not installed", "run: python -m ensurepip --upgrade"
assert os.path.isdir(sys.prefix), "sys.prefix points at a missing folder"

On a fresh install inside a .venv the script prints something like:

python:   3.12.4 (CPython)
venv:     active
prefix:   /home/you/projects/demo/.venv
pip:      24.0
platform: Linux-6.5.0-x86_64-with-glibc2.38
cwd:      /home/you/projects/demo