Run Python on your own machine

Everything so far ran in your browser — convenient for learning, but it's a sandbox. Real building happens on your own computer, where you can save files, install any package from PyPI, talk to the network, and run programs that last longer than a tab. This lesson is the move from "learner" to "developer." It's a how-to, not a coding exercise, so there's no runnable challenge — just a clear path and a checkpoint quiz at the end. Follow it once and you'll have a working Python setup you'll use for every guide above this one.

Step 1 — Install Python

Go to the official site, python.org/downloads, and download the latest Python for your operating system. Run the installer.

:::warning Windows: check "Add Python to PATH" On Windows, the very first installer screen has a checkbox: "Add python.exe to PATH." Check it before clicking Install. PATH is the list of places your computer looks for programs; adding Python to it is what lets you type python in any terminal and have it found. Miss this box and the terminal will say "python is not recognized" — the single most common beginner snag. (On macOS the installer handles this for you.) :::

To confirm it worked, you'll use the terminal — which is Step 2.

Step 2 — The terminal (command line)

The terminal (also called the command line, shell, or console) is a text window where you type commands instead of clicking. It feels old-fashioned, but it's how developers run Python, install packages, and use Git. You only need a handful of commands.

How to open one:

Windows — open PowerShell (search for it in the Start menu). The newer Windows Terminal is also great.
macOS — open Terminal (in Applications → Utilities, or search with Spotlight).

The terminal always sits in a folder (the "current directory"). These commands move around and look at files. A few differ between Windows PowerShell and macOS/Linux:

Goal	Windows (PowerShell)	macOS / Linux
Show current folder	`pwd`	`pwd`
List files here	`ls`	`ls`
Change into a folder	`cd projects`	`cd projects`
Go up one folder	`cd ..`	`cd ..`
Make a new folder	`mkdir myapp`	`mkdir myapp`

Now confirm Python installed correctly. Type:

python --version

You should see something like Python 3.13.1. If you do, Python is installed and on your PATH — you're ready.

:::note python vs python3 On macOS and Linux the command is often python3 (and pip3), because plain python historically meant an ancient version. On Windows it's usually python. If one doesn't work, try the other. Throughout these notes, when you see python, use whichever your system answers to. :::

Step 3 — Create a project folder

Keep each project in its own folder. In the terminal:

mkdir myfirstapp
cd myfirstapp

You're now inside myfirstapp. Everything in the next steps happens here.

Step 4 — Virtual environments: a clean bubble per project

Here's a problem you'll hit fast. Project A needs version 1 of some package; Project B needs version 2. Install both onto your system globally and they collide. The fix is a virtual environment (or venv): a private, isolated copy of Python just for one project, with its own packages that can't interfere with anything else. Every real project gets one.

Create one inside your project folder:

python -m venv .venv

Read that as: "Python, run the venv module (-m means 'run this module'), and create an environment in a folder called .venv." The name .venv is just a convention. This makes a .venv folder holding a private Python.

Creating it isn't enough — you must activate it, which points your terminal at that private Python for the current session:

# Windows (PowerShell)
.venv\Scripts\Activate.ps1

# macOS / Linux
source .venv/bin/activate

Once activated, your prompt usually shows (.venv) at the start of the line — that's how you know you're inside the bubble. Now python and pip refer to the project's private copies. When you're done working, type deactivate to leave it.

:::warning Windows: if activation is blocked PowerShell may refuse the activation script with an "execution policy" error the first time. Run this once to allow local scripts, then activate again: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned It's a one-time setting, not something you repeat per project. :::

:::tip Why python -m venv and python -m pip The -m form means "use this exact Python's tools." When several Pythons are installed, python -m pip install ... guarantees the package lands in the Python you're actually running — sidestepping the classic "I pip-installed it but import still fails" confusion. Make python -m your default habit. :::

Step 5 — Install packages into the venv

With the venv active, install any package you need from PyPI:

pip install requests

Because the venv is active, requests installs into this project only — not system-wide. Other projects are unaffected. This is exactly the pip install from the modules lesson, now landing in the right place.

A professional habit: record your project's packages in a requirements.txt file so anyone (including future you) can recreate the environment:

pip freeze > requirements.txt        # write the current packages to the file
pip install -r requirements.txt      # later, on another machine: install them all

Step 6 — Write and run a .py file

A Python program lives in a file ending in .py. Create one in your project folder with any text editor — VS Code is the standard free choice and pairs beautifully with Python. Put this in a file called hello.py:

# hello.py
import requests   # works because we pip-installed it into the venv

name = "world"
print("Hello,", name)
print("Two plus two is", 2 + 2)

Then, in the terminal (venv still active, sitting in the same folder), run it:

python hello.py

You'll see your output printed. That's it — that's a real program, running on your machine, that you wrote, with a real package installed. The full loop you'll repeat forever: edit the .py file → run python file.py → read the output (or the traceback) → fix → run again. It's the same edit-run-debug loop you've been doing in the browser, now on your own computer with the whole Python ecosystem available.

The full sequence, start to finish

Here's the entire workflow in one place — the recipe for starting any new Python project:

mkdir myproject          # 1. make a project folder
cd myproject             # 2. go into it
python -m venv .venv     # 3. create a virtual environment
# 4. activate it (pick your OS):
#    Windows:  .venv\Scripts\Activate.ps1
#    mac/Linux: source .venv/bin/activate
pip install requests     # 5. install packages you need
python myproject.py      # 6. run your program

Do this a couple of times and it becomes muscle memory. Every guide above this one assumes you can.

Why it matters

The in-browser sandbox got you this far, but you can't ship from a browser tab. Installing Python, living in the terminal, isolating projects with a venv, installing packages, and running .py files — that's the baseline working environment of every developer, and every guide ahead of you assumes it. Set it up once and the AI, web, and security guides become things you can actually do, not just read. This is the lesson that makes you dangerous.

Where this leads: every project in the next guides starts with exactly this setup — venv, pip install, run. See Where this leads next.

Checkpoint

Required checkpoint