Getting Started with Python
Read the smallest useful Python program line by line, then set the language up the way professionals actually do — uv, virtual environments, and the right tool for each job.
What you'll learn
- How to read a tiny Python program and know what every line does
- The right way to install Python locally for real projects
- Why a virtual environment is the one setup habit you cannot skip
- When to use the REPL, a script, and a Jupyter notebook
Open a terminal, type python, and press Enter. A short prompt appears — >>> — and the language is now sitting there, waiting for you to say something. Type print("hello") and it answers back, hello. That tiny exchange is the whole of Python in miniature: you say something, it does it, and it shows you the result.
Most tutorials open with a long installation checklist, as if setup were the hard part. It is not. The hard and interesting part is the language, so let us begin there — with the smallest program worth reading — and come back to a proper install once you have something to install it for.
Read your first program
Here is a complete Python program. Before we run anything, read it as you would read a sentence, top to bottom:
name = "world"
print(f"Hello, {name}!")
print(f"Welcome to Python.")
print(f"2 + 2 = {2 + 2}")
Run it, and it prints exactly this:
Hello, world!
Welcome to Python.
2 + 2 = 4
Three things just happened, and each is worth a sentence. The first line binds the name name to the text "world" — no type declaration, no semicolon, just a name and a value. The print(...) calls send text to the screen. And the f"..." is an f-string: a string literal where anything inside { } is evaluated and dropped in, so {name} became world and {2 + 2} became 4. You will write f-strings in nearly every program you ever make, so it is a good first friend.
A program that does something useful
Counting the words in a piece of text is the “hello world” of data work — small enough to read, real enough to be useful. Suppose we want the five most common words in a short paragraph:
from collections import Counter
text = """
Python is dynamic. Python is fast enough for most data work.
Python has a huge ecosystem. Python is opinionated about readability.
"""
words = text.lower().split()
counts = Counter(words)
for word, n in counts.most_common(5):
print(f"{n:>3} {word}")
It prints:
4 python
3 is
1 dynamic.
1 fast
1 enough
Read it the same way. We lower-cased the text and .split() it on whitespace into a list of words; Counter tallied how many times each word appears; and .most_common(5) handed back the top five, highest first. The headline is honest — python really is the most common word, four times over.
One detail rewards a closer look. The word dynamic. still carries its full stop, because .split() breaks only on spaces — it has no idea that a period is punctuation. Real text cleaning needs more than that, which is exactly what the regex lesson is for. For now, notice that Counter came built in: Python ships with hundreds of small, sharp tools like it in its standard library, and reaching for those before installing anything is a habit worth forming early.
Now install Python — properly
For real work you want Python on your own machine, and here the ecosystem has earned its reputation: it has perhaps the messiest installation story in software. So let us get it right in one pass.
The one rule that saves the most pain: do not use the Python that came with macOS or Linux. That is the system Python, the operating system leans on it, and changing it can break OS tools in ways that are miserable to undo. Install your own instead:
- macOS / Linux — install uv with
curl -LsSf https://astral.sh/uv/install.sh | sh - Windows — get the installer from python.org, or run
winget install Python.Python.3.12
Then check it answers:
python --version
# Python 3.12.x
Virtual environments — the one habit you cannot skip
Here is the single setup idea that matters most, so let us name it plainly. A virtual environment is a private, per-project Python install — its own copy of the interpreter and its own folder of packages. Without one, every project shares one global pile of libraries, and the day project A needs an old version of a package while project B needs the new one, you are stuck. With one, each project keeps its own dependencies, sealed off from the others.
With uv, the whole loop is four lines:
mkdir hello && cd hello
uv init # creates pyproject.toml + .venv
uv add pandas numpy # installs into .venv, not globally
uv run main.py # runs your script inside the venv
REPL, script, or notebook?
You will run Python in three different places, and choosing the right one for the moment keeps your work tidy:
| Tool | When to reach for it |
|---|---|
REPL (run python in a terminal) | Quick experiments; poking at a library to learn its API |
Script (a .py file) | Anything you will re-run, share, or deploy |
Jupyter notebook (.ipynb) | Data exploration, model training, sharing results with charts |
The common trap is to use notebooks for everything. They are wonderful for exploration, but they version-control badly and hide bugs in stale, out-of-order cells. Once code is something you will keep, move it into .py files.
In one breath
- A Python program is read top to bottom; a name binds to a value with no type declaration.
- An f-string evaluates anything inside
{ }and inserts the result. - Install your own Python with uv — never modify the system one.
- A virtual environment isolates each project’s packages; it is the one habit you cannot skip.
- Use the REPL to explore, a script for anything real, a notebook for data exploration.
Practice
Quick check
What’s next
You can read a small program, install Python the professional way, and keep each project’s dependencies to itself. Next we look at the language’s own rules of grammar — how Python uses indentation instead of braces, and the style conventions that make Python code unusually pleasant to read.