Python Installation — Quick-Pick

What it is

Python is a dynamically-typed, interpreted, general-purpose language known for its readable syntax and enormous ecosystem. Created by Guido van Rossum and stewarded by the Python Software Foundation, it is the dominant language for data science, machine learning, scripting, web backends, and automation. This page covers the fastest way to get a working Python installation on Windows, macOS, or Linux and verify it is ready to use.

Recommended version

Always use a version ≥ 3.12 for new projects unless a dependency forces otherwise.

Quick install by OS

Verify any installation

python --version
python3 --version
pip --version

Output:

Python 3.12.3
Python 3.12.3
pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12)

On Linux and macOS the default command may be python3, not python. Always check which one points to your intended version.

After installing

Set up a virtual environment before installing any packages:

python -m venv .venv
source .venv/bin/activate   # Linux / macOS / WSL
.venv\Scripts\activate      # Windows PowerShell

See Virtual Environments for full details.

Choosing an interpreter — CPython vs alternatives

"Python" is a language specification, and several runtimes implement it. CPython is the reference implementation maintained by the Python Software Foundation and ships from python.org. Reach for an alternative only when you have a specific reason — most libraries assume CPython, and the C-extension ecosystem (NumPy, pandas, PyTorch) is best-supported there.

CPython 3.13 introduced an experimental free-threaded build (sometimes called "no-GIL Python") gated behind a separate python3.13t binary. It is opt-in, slower for single-threaded workloads, and only useful for CPU-bound concurrent code — leave it off unless you are benchmarking the GIL specifically.

Choosing an install mechanism

The single biggest decision is how Python lands on your machine. Each mechanism has different trade-offs around update cadence, multi-version support, and disk layout.

Decision flowchart

A short decision tree that matches most situations. Pick the first row whose question you answer "yes" to.

When in doubt in 2026, start with uv — it installs Python itself, creates virtual environments, resolves dependencies, and runs scripts, all with a single binary and no Python prerequisite.

The modern path — uv python

uv ships its own Python distribution mechanism (uv python install) that pulls statically-linked CPython builds from the python-build-standalone project. It is the fastest way to land a specific Python version on a fresh machine because there is no compiler step and no global state to corrupt.

# Install uv first (no Python required)
curl -LsSf https://astral.sh/uv/install.sh | sh         # macOS / Linux
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"   # Windows

# Install a specific Python
uv python install 3.12

# Install several
uv python install 3.11 3.12 3.13

# List installed and discovered interpreters
uv python list

# Pin a version for the current project (writes .python-version)
uv python pin 3.12

Output:

Installed Python 3.12.3 in 1.42s
 + cpython-3.12.3-linux-x86_64-gnu (python3.12)

uv python install writes interpreters under ~/.local/share/uv/python/ (Linux/macOS) or %APPDATA%\uv\python\ (Windows). It does not touch your system PATH unless you explicitly run uv tool update-shell, which means uv-managed Pythons coexist safely with Homebrew, pyenv, or the distro package.

The python-build-standalone tarballs uv uses are unofficial but production-grade — they are the same builds Astral's CI uses internally and have been adopted by Hatch, Rye, and PyApp.

pyenv, asdf, and mise — version managers compared

When you need more than one Python version on a machine (rare on a personal laptop, common on shared dev boxes and CI), a version manager is the right tool. All three of these set the python and python3 on PATH to whatever the current project says it wants, via a .python-version (or .tool-versions) file checked into the repo.

# pyenv — Python-only, mature, the de facto standard
brew install pyenv          # or: curl https://pyenv.run | bash
pyenv install 3.12.3
pyenv global 3.12.3
echo '3.12.3' > .python-version

# asdf — polyglot, plugin-based
brew install asdf
asdf plugin add python
asdf install python 3.12.3
asdf global python 3.12.3

# mise — modern asdf successor, Rust-based, much faster shell init
brew install mise
mise use --global python@3.12
mise use python@3.12        # writes .tool-versions in the current dir

If you are starting fresh in 2026, prefer mise over asdf — it reads the same .tool-versions files but starts your shell in single-digit milliseconds and ships precompiled Python binaries by default.

conda, mamba, micromamba

The conda ecosystem (Anaconda, Miniconda, Miniforge, mamba, micromamba) manages Python and the native libraries Python links against — CUDA toolkits, Intel MKL, ffmpeg with proprietary codecs, R, Julia, and more. It is heavyweight compared to pip + uv but is the standard in scientific computing, GPU machine learning, and bioinformatics.

# Miniforge — recommended over plain Miniconda (uses conda-forge by default)
curl -LO https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh
bash Miniforge3-*.sh -b -p ~/miniforge3
~/miniforge3/bin/conda init bash

# Create an environment with a specific Python and CUDA-enabled PyTorch
conda create -n ml python=3.12 pytorch cuda-version=12.4 -c pytorch -c nvidia
conda activate ml

Anaconda Inc.'s commercial Terms of Service apply to organizations with more than 200 employees using the defaults channel. Miniforge defaults to conda-forge instead and is unaffected — the safer choice for businesses.

Official downloads

The python.org installer is still the most predictable option when you want one signed, official binary on a machine and no other tooling.

PGP signatures and SHA-256 sums for every release are published at https://www.python.org/downloads/release/python-XYZ/. Production installs should verify both.

# Verify a source tarball before building
gpg --recv-keys 7169605F62C751356D054A26A821E680E5FA6305
gpg --verify Python-3.12.3.tgz.asc Python-3.12.3.tgz
sha256sum -c <(echo "<expected-sha>  Python-3.12.3.tgz")

Per-OS quick reference

Each of these links goes to a deep-dive page with copy-paste commands, package manager comparisons, troubleshooting tables, and post-install recipes.

Post-install verification

Run all of these after any new install. The point is to confirm you are launching the Python you expect, that pip is wired to that Python (not a different one further along PATH), and that the standard library is complete enough to bootstrap a virtual environment.

# 1. Which Python is on PATH?
which python python3 || where python python3

# 2. Version of that Python
python --version
python3 --version

# 3. Is pip wired to the same interpreter?
python -m pip --version

# 4. Does the venv module work?
python -m venv /tmp/_probe && rm -rf /tmp/_probe && echo 'venv OK'

# 5. Does SSL work? (TLS cert store missing is a common Mac/Linux bug)
python -c "import ssl; print(ssl.OPENSSL_VERSION)"

# 6. Can you reach PyPI?
python -m pip install --dry-run requests

Output:

/opt/homebrew/bin/python
/opt/homebrew/bin/python3
Python 3.12.3
Python 3.12.3
pip 24.0 from /opt/homebrew/lib/python3.12/site-packages/pip (python 3.12)
venv OK
OpenSSL 3.3.0 9 Apr 2024
Would install requests-2.32.3 certifi-2024.7.4 charset-normalizer-3.3.2 idna-3.7 urllib3-2.2.2

Common pitfalls

Two Pythons fighting on PATH — python may resolve to one install while pip resolves to a different one. Always invoke python -m pip (not bare pip) so the package manager runs against the interpreter you actually launched.

pip install outside a virtual environment — Modern Debian/Ubuntu and Homebrew Python both refuse this with error: externally-managed-environment (PEP 668). Create a venv first, or pass --user only for tools you genuinely want global.

Windows store stubs — Typing python on a fresh Windows install opens the Microsoft Store, not a real Python. Install via winget or python.org first; the stub is bypassed automatically.

macOS system Python — /usr/bin/python3 exists but only as a prompt to install Xcode Command Line Tools. Do not pip install against it; use Homebrew, pyenv, or uv.

make install from source on Linux — Always use sudo make altinstall, never make install. The former installs python3.12 without touching the python3 symlink your distro depends on.

Real-world recipes

Concrete patterns for common situations. Each one is a complete sequence you can paste into a fresh terminal.

Fastest possible fresh install (any OS)

# 1. Install uv (no Python required)
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2. Install Python + create a project
uv python install 3.12
uv init my-project && cd my-project
uv add requests
uv run python -c "import requests; print(requests.__version__)"

Multiple Python versions for tox / CI parity

# Using uv
uv python install 3.10 3.11 3.12 3.13

# Using pyenv
pyenv install 3.10.14 3.11.9 3.12.3 3.13.0
pyenv global 3.12.3 3.13.0 3.11.9 3.10.14   # all visible, 3.12 default

# Verify
python3.10 --version
python3.11 --version
python3.12 --version
python3.13 --version

Locked-down corporate machine (no admin)

# Windows — scoop installs to %USERPROFILE%, no UAC
iwr -useb get.scoop.sh | iex
scoop install python

# macOS / Linux — uv installs to ~/.local, no sudo
curl -LsSf https://astral.sh/uv/install.sh | sh
uv python install 3.12

CI runner that needs a specific Python in seconds

# GitHub Actions — actions/setup-python is fine, but uv is faster
- uses: astral-sh/setup-uv@v3
- run: uv python install 3.12
- run: uv sync
- run: uv run pytest

Data-science workstation with CUDA

# Miniforge + mamba is the path of least resistance for GPU machine learning
curl -LO https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh
bash Miniforge3-*.sh -b -p ~/miniforge3
~/miniforge3/bin/mamba init bash
mamba create -n torch python=3.12 pytorch torchvision cuda-version=12.4 -c pytorch -c nvidia
mamba activate torch
python -c "import torch; print(torch.cuda.is_available())"

Rebuilding from a .python-version file

# If a repo has .python-version, the tool will read it automatically:
cat .python-version           # e.g. "3.12.3"
uv python install             # uv reads .python-version
pyenv install                 # pyenv reads .python-version
mise install                  # mise reads .tool-versions

Where Python lands on disk

Knowing where each mechanism writes files helps you debug PATH collisions and clean up later.

Version lifecycle and EOL planning

CPython releases follow a predictable cadence — a new minor version every October, supported for five years (one year of "bugfix" and four years of "security"). Knowing the schedule helps you pick a target version that will still be supported when your project ships.

For long-lived projects, target the two-most-recent minor versions and run CI against both. This gives you ~2 years of runway before you need to drop the older one. For libraries with a requires-python constraint, prefer >=3.10 in 2026 unless you have a specific reason to support 3.9.

# pyproject.toml — sensible defaults for a new library in 2026
[project]
requires-python = ">=3.10"
classifiers = [
    "Programming Language :: Python :: 3.10",
    "Programming Language :: Python :: 3.11",
    "Programming Language :: Python :: 3.12",
    "Programming Language :: Python :: 3.13",
]

The single most important thing to track on a long-lived codebase is which Python version is most-used in CI. When the youngest tested version goes EOL, drop it, bump requires-python, and add the newest stable to the matrix.

How to read which python output

which python (or which -a python, type python, command -v python) is the first diagnostic tool when something is wrong. What it shows tells you a lot.

# Show every match, not just the first
which -a python python3
type -a python python3
command -v python; command -v python3

# Show the resolved real path (after symlinks)
readlink -f "$(command -v python3)"

Output:

/home/alice/.pyenv/shims/python3
/usr/bin/python3
/home/alice/.pyenv/versions/3.12.3/bin/python3.12

What gets shipped with Python

A fresh Python install gives you more than just the python interpreter. Knowing the bundled tools means you can avoid installing redundant ones.

# Inspect what came in the box
python -c "import sysconfig; print(sysconfig.get_paths())"
python -c "import sys; print(sys.path)"
python -c "import sys; print(sys.builtin_module_names)"
python -m pydoc -p 8000          # docs server on http://localhost:8000

Multi-architecture builds (arm64, x86_64, RISC-V)

In 2026, most laptops are arm64 (Apple Silicon, Snapdragon X, Ampere) or x86_64 (Intel, AMD). Wheel publishers usually ship binaries for both, but native compilations from source pick whichever architecture you're running on.

# What architecture am I on?
uname -m              # arm64, aarch64, x86_64, riscv64
arch                  # macOS — same idea
python -c "import platform; print(platform.machine(), platform.processor())"

# What wheel does pip prefer?
python -c "import pip; from pip._internal.utils.compatibility_tags import get_supported; [print(t) for t in get_supported()[:5]]"

Output:

arm64
arm64
arm64 arm
cp312-cp312-macosx_14_0_arm64
cp312-cp312-macosx_14_0_universal2
cp312-abi3-macosx_14_0_arm64
cp312-cp312-macosx_13_0_arm64
cp312-cp312-macosx_12_0_arm64

Mixing architectures in a single venv breaks everything. If a project is venv-locked to x86_64 wheels (because someone installed on Rosetta) and you switch to native arm64, delete .venv and recreate it under the right architecture.

Where to learn more

External references that go deeper than this page can:

• Official docs — https://docs.python.org/3/using/index.html
• python-build-standalone — https://github.com/indygreg/python-build-standalone
• python.org Beginner's Guide — https://wiki.python.org/moin/BeginnersGuide/Download
• PEP 668 (externally-managed-environment) — https://peps.python.org/pep-0668/
• PEP 711 (PyBI distributions) — https://peps.python.org/pep-0711/

Next steps

Once Python is on the machine, the standard onboarding path is:

1. Create a virtual environment per project — see Virtual Environments.
2. Pick a package manager — see pip vs uv.
3. Define project metadata — see pyproject.toml.
4. Lint and format — see ruff.
5. Test — see pytest.