beginner25 minby DevFox

Why Python and What Happens When You Run It

What a programming language is for, what actually happens between saving a file and seeing output, and the difference between typing at the interpreter and writing a program that lasts.

Python

There are four hundred photographs on your desktop with names like IMG_4471.JPG, and you need them named by the date they were taken. You could do it by hand. It would take an evening, you would start making mistakes around photo two hundred, and next month another four hundred would arrive.

That gap — between a task a person can describe in one sentence and a task a person can bear to do — is where programming lives. By the end of this lesson you will have written a program, run it, understood what your computer actually did with it, and read your first error message without panicking. You need no experience at all.

What a program actually is

A program is a list of instructions precise enough that a machine can follow them without asking you anything.

That last part is the whole difficulty. Ask a colleague to "rename the photos by date" and they will work out what you meant. They know a photo taken at midnight belongs to that day, they know what to do about two photos from the same second, and they know to come and ask if something looks odd. A computer knows none of that. It does exactly what you wrote, at enormous speed, and if what you wrote was wrong it does the wrong thing four hundred times without hesitating.

So a program is not a request. It is a recipe written for someone extraordinarily fast, perfectly obedient, and with no judgement whatsoever.

A programming language is the notation you write that recipe in. It exists because the instructions a processor actually understands are unbearable to write by hand — millions of steps like "copy this number into that slot". A language lets you write something a human can read, and hands the tedium of translating it to a program built for exactly that job.

Why this language

Python is a programming language designed to be read.

That sounds like a soft benefit. It is the practical one. You will spend far more time reading code — your own, from three months ago, when you have forgotten all of it — than writing it. Here is a complete Python program that adds up a column of numbers in a file:

python

total = 0

with open("sales.txt") as file:
    for line in file:
        total = total + float(line)

print(total)

You can very nearly read that aloud in English. Start a total at zero, open the file, take each line in turn, add it to the total, print the answer. Most languages ask you to say considerably more to do the same thing.

The second reason is that a great deal comes with it. Reading files, fetching web pages, handling dates, doing arithmetic on large tables, running a web server — most of what you will want either ships with Python or is one install away, written by somebody who already found the awkward cases.

What happens when you run a file

You save a file called sales.py, you type one line, and numbers appear. Between those two moments there are three steps, and knowing them will save you hours later.

Your file is read as text
Nothing has run yet. Your program is characters, checked only for whether it is shaped like Python.
The text becomes bytecode
A compact list of simple operations, much closer to what a machine works in. You never see it; Python caches it so it need not repeat the work.
The interpreter performs them
The program called python walks through those operations one at a time. This is when your file is really opened and your numbers really added.

Every time you run a Python file, in order

The word for all three together is running your program. And the way that third step works explains something that confuses every beginner.

Translate the whole book first

Convert everything in advance, then ship the translation.

Nothing runs until the whole text has been converted, so a mistake on line ninety is found before line one happens. C, Go and Rust work broadly like this.

A translator reading beside you

Take it a piece at a time and perform it as you go.

Python's way. Work gets done as it is reached — which means a mistake on line ninety is discovered on line ninety, after lines one to eighty-nine have already happened.

Two ways a language can get from your text to a result

That is not a subtle difference. Python will happily run the first half of a broken program:

python

print("Starting the report")
print("Total:" + 5)

Run this and Starting the report appears on your screen, then an error. The first line ran. The second failed. Nobody checked the whole file for problems first, because that is not how the thing works.

Two ways to talk to Python

There are two ways to hand Python your instructions, and they are for two genuinely different jobs.

The first is the interactive interpreter, usually called the REPL — it Reads what you type, Evaluates it, Prints the answer, and Loops back for more. Start it by typing python3 on its own and pressing Enter:

text

$ python3
Python 3.12.4
>>> 2 + 2
4
>>> "photo" + "graph"
'photograph'
>>> exit()

Those >>> marks are Python's prompt, telling you it is waiting. Notice it answered immediately — you never asked it to print anything, it just showed you. That makes it superb for questions you want answered right now. What does this function return? Is this text really what I think it is?

The second way is a script: your instructions saved in a file, which you run whenever you like.

bash

python3 rename_photos.py      # run the instructions in this file

Here is the distinction that matters, and the mistake that teaches it.

Bad — an afternoon of real work typed into the REPL.

text

>>> import os
>>> files = os.listdir("photos")
>>> # ...forty more lines, carefully worked out...
>>> exit()

Good — the same work in a file you saved.

python

# rename_photos.py
import os

files = os.listdir("photos")
# ...the same forty lines, in a file...

Close the REPL and everything in it is gone — not archived, not recoverable, gone. Those forty lines cannot be run again tomorrow, cannot be corrected when you spot the mistake, and cannot be given to anyone. A file can be run ten thousand times, fixed, improved and shared. Use the REPL to answer a question; use a file for anything you would be annoyed to lose.

Writing and running one

Make a file called hello.py. Any text editor will do. Put this in it:

python

print("Hello. Nothing is on fire.")

Save it, then in a terminal, in the same folder:

bash

python3 hello.py

text

Hello. Nothing is on fire.

That is a program. It is a small one, but every part of the process you will use for the next ten years is already there: you wrote instructions in a file, an interpreter read them, and something happened.

print is a function — a named piece of behaviour you use by writing its name followed by parentheses. Whatever goes inside the parentheses is what it works on. You will meet functions properly later; for now, print puts things on the screen, and it is how you find out what your program is thinking.

Now something with a moving part:

python

name = input("What is your name? ")
print("Hello, " + name + ". Nothing is on fire.")

text

$ python3 hello.py
What is your name? Antonii
Hello, Antonii. Nothing is on fire.

input stops and waits for you to type something, then hands back what you typed. name = stores it under a name so the next line can use it. Two lines, and the program now behaves differently depending on what it is given — which is the entire idea, in miniature.

Errors are the normal case

You will see far more errors than you expect, and that is not a sign anything has gone wrong with you. Experienced programmers produce errors constantly. They have stopped finding them alarming, which is a different thing from not causing them.

Make one deliberately. Change the file to:

python

print("Total:" + 5)

text

Traceback (most recent call last):
  File "hello.py", line 1, in <module>
    print("Total:" + 5)
                     ~~~~~~~~~~^~~
TypeError: can only concatenate str (not "int") to str

That is a traceback, and it is trying to help. The trick is that it is written in the opposite order from how you should read it.

The last line — the actual complaint
TypeError names the kind of problem. The rest of the line is the specific one: + between two pieces of text joins them, between two numbers adds them, and Python will not guess when you mix one of each.
Just above it — where it happened
The file, the line number, and the line itself with the trouble spot marked underneath.
Everything higher — how you got there
The route the program took to reach the problem. Useful once the bottom two are not enough, and rarely before that.

Read a traceback in this order, not top to bottom

The fix here is to say which you meant:

python

print("Total: " + str(5))   # turn the number into text, then join

A cheat sheet to keep

text

WHAT THINGS ARE
  program        instructions precise enough to need no judgement
  language       the readable notation you write them in
  interpreter    the `python3` program that carries them out
  bytecode       the compact form your text is turned into first
  script         your instructions saved in a .py file
  REPL           the interactive prompt, for asking questions
  function       named behaviour, used as name(...)
  traceback      the report printed when something fails

COMMANDS
  python3                 start the interactive prompt
  python3 hello.py        run the instructions in a file
  exit()                  leave the interactive prompt
  print("text")           show something on screen
  input("prompt? ")       wait for the user to type something
  str(5)                  turn a number into text

HABITS THAT PAY IMMEDIATELY
  run it early     five lines at a time, not sixty
  file, not REPL   anything you would mind losing goes in a file
  read upward      the last line of a traceback is the complaint
  print freely     when unsure what a program thinks, print it

Where to go next

You now know what a program is, what happens between saving a file and seeing output, when to use the prompt and when to use a file, and how to read the first thing that goes wrong. That is genuinely the foundation — everything else in this course sits on top of those four things.

Next is Installing Python Without Breaking Your Machine. This lesson quietly assumed that typing python3 works on your computer, and for a good number of readers it does not, or it starts something older than you want. That lesson sorts it out properly: why your machine may already have a Python you should leave alone, how more than one version lives side by side, and how to end up with a setup you can trust.

Before you move on, write one small program that does something you actually want. It does not matter how trivial. Ask for two numbers and print their total; ask for a name and print it fifteen times. The point is not the program — it is going all the way round the loop yourself, from an empty file to something that runs, errors in the middle included. Do that once and the rest of this course is detail.