Kiru Lab / Foundations: Python as an Instrument / Getting Set Up
Your First Program
A file, some text, one command. Everything else in this curriculum is an elaboration of this.
Hands-On Lab · about 40 minutes
A Python program is a plain text file whose name ends in .py. When you run it, the interpreter reads the lines from top to bottom and does what each one says. There is nothing more mysterious happening than that.
Write it
In your kiru-lab folder, create a file called `hello.py` and type this in — actually type it, do not paste. Typing forces you to notice the syntax.
name = "engineer"
print("Hello,", name)
years = 2
print("In", years, "years this will feel easy.")Run it
python3 hello.py
# Hello, engineer
# In 2 years this will feel easy.That is a program. It has variables, it has function calls, and it produces output. Every model you will train later is this, plus a great deal of arithmetic.
The interactive shell
Typing `python3` on its own opens a shell where each line runs as you type it. This is the right tool for asking small questions — what does this function return, what type is this thing — and the wrong tool for anything you want to keep. Use the shell to explore, files to build.
$ python3
>>> 2 + 2
4
>>> "engineer".upper()
'ENGINEER'
>>> len("mechanistic")
11
>>> exit()Comments
Anything after a `#` is ignored by Python. Comments are for explaining why a line exists, not what it does — the code already says what it does, and a comment that restates it will go stale and start lying.
total = total + 1 # increment total by 1 <- useless, says what
# Offset by one because the API returns pages numbered from 1, not 0.
page = index + 1 # <- useful, says whyCopying code teaches you almost nothing. Typing it makes you confront every colon, bracket, and indent, and the errors you generate by mistyping are how you learn what the syntax actually requires. Slow is fast here.
Hold on to
- A program is a text file the interpreter reads top to bottom
- The interactive shell is for exploring; files are for building
- Comments explain why, not what
Work through
Try each one before opening the solution. Getting it wrong first is most of where the learning happens.
-
Write and run a program that prints your name, the current year, and one sentence about why you are learning this. Keep the file — reread it when you finish track 7.
Hint
Three print statements, or one f-string containing all three pieces.
Solution
Any working version is correct. The point of keeping the file is that in six months you will read it and be surprised at how much has changed.
name = "your name here" year = 2026 reason = "I want to understand the systems I build, not just call them." print(f"{name}, {year}") print(reason) -
Open the interactive shell and find out what `"mechanistic interpretability".split()` returns. Describe the result in your own words.
Hint
Type it into the interactive shell and look at the result.
Solution
`.split()` returns a list of the words: `['mechanistic', 'interpretability']`. It cuts the string at whitespace and hands back the pieces. This is the first, crudest form of tokenization — the same operation that opens track five, before subword schemes make it more interesting.
>>> "mechanistic interpretability".split() ['mechanistic', 'interpretability'] -
Deliberately break `hello.py` by removing a closing quotation mark. Run it, read the error, then fix it. You have now seen your first SyntaxError on purpose rather than by accident.
Hint
Read the line number in the error, then look at that line and the one above it.
Solution
You get a SyntaxError — Python could not finish parsing the string, so it never ran a single line of the file. This is the key property of a SyntaxError: it is a failure to read your code, not a failure while running it. Note that the reported line may be the one after the real mistake, because that is where Python finally gave up.
Sign in to track your progress through the lab.