What Is State in a Program?

Layer 3 begins. Everything so far has been static — built once and read. State is data that legitimately changes while a program runs, and tracking it correctly is a skill of its own.

1. Learning Objective

2. Pre-Coding Quiz

Answer these before reading the concept explanation or writing any code. It is fine to get these wrong — that is the point. You need 4/5 to proceed to the lab.

3. The Concept — State

State is data that changes while the program runs

Every attribute we have written so far has technically been mutable — but not every attribute is meant to change. "State" specifically means data that is expected and designed to change over the lifetime of a running program, in response to something happening.

class Country:
    def __init__(self, name, region, population):
        self.name = name          # fixed identity — not expected to change
        self.region = region      # fixed identity — not expected to change
        self.population = population  # STATE — expected to change over time

Construction-time data vs state

Session 15 established that data arrives explicitly through the constructor. Some of that data stays fixed for the object's lifetime (like name); other data is the object's starting state, expected to evolve afterward (like population, which grow_population already updates).

A collection can be state too

CountryExplorer.countries is state — it grows as data loads, and potentially shrinks or reorders based on user actions later in the project.

class CountryExplorer:
    def __init__(self, countries):
        self.countries = countries  # starts here, but this list is STATE — it changes over time

explorer = CountryExplorer(countries=[])
explorer.countries.append(Country(name="Kenya", region="Africa", population=54000000))
# .countries just changed shape — this is state changing over the program's lifetime

Why uncontrolled mutation is risky

If any part of a large program can reach in and mutate shared state directly, tracing an unexpected value back to its cause becomes very difficult — there is no single place to look. The next several sessions build the discipline of changing state only through deliberate, well-named methods.

# Risky — anyone, anywhere, can silently corrupt state
explorer.countries[0].population = -999999  # no validation, no traceability

# Better (Session 21 formalizes this) — a controlled method with rules
explorer.countries[0].grow_population(1000000)  # validated, named, traceable

4. Lab

What you will build

A file called state_concept.py — mostly comments and small demonstrations, not new functionality.

Step-by-step instructions

# state_concept.py
class Country:
    def __init__(self, name, region, population):
        self.name = name
        self.region = region
        self.population = population

class CountryExplorer:
    def __init__(self, countries):
        self.countries = countries

class Country:
    def __init__(self, name, region, population):
        self.name = name              # FIXED — identity, not expected to change
        self.region = region          # FIXED — identity, not expected to change
        self.population = population  # STATE — expected to change over time (Session 14)

class CountryExplorer:
    def __init__(self, countries):
        self.countries = countries    # STATE — grows/shrinks as data loads (Session 16)

k = Country(name="Kenya", region="Africa", population=54000000)
k.population = -999999   # directly assigned, bypassing any validation
print(k.population)      # -999999 — nothing stopped this

explorer = CountryExplorer(countries=[k])
same_explorer = explorer  # NOT a copy — same reference

same_explorer.countries.append(Country(name="Ghana", region="Africa", population=31000000))
print(len(explorer.countries))       # 2 — the change is visible through BOTH names
print(len(same_explorer.countries))  # 2

5. Expected Files Changed

6. Commit Checkpoint

Once the lab is complete and you can explain every line, make this exact commit:

git add state_concept.py docs/sessions/session-20/index.html
git commit -m "session-20: identify state vs fixed attributes and observe uncontrolled mutation risk"

7. Code Review Checklist

Go through your code line by line and check each item:

8. Post-Coding Quiz

Same 5 questions. Take it again now that you have written and run the code. You need 4/5 to mark this session complete.

9. Reflection Questions

Think through these after the post-quiz. No right answer — they are for discussion.

10. What Breaks If This Knowledge Is Missing?

11. What We Learned