What Survives When the Program Dies?

Core path: 30 minutes

A variable can feel permanent while you are staring at it in a running program.

It is not.

Kill the process and ordinary runtime memory disappears with it.

Persistence begins when the program deliberately stores information somewhere that outlives the process.

Prove the difference between memory and disk

Run this:

score = 950
print(score)

Close the program.

Start it again.

Where did 950 go?

Now save the same information to a file:

import json

with open("score.json", "w") as file:
    json.dump({"score": 950}, file)

Stop the program completely.

Then load:

with open("score.json", "r") as file:
    data = json.load(file)

print(data["score"])

The process that created the file is gone. The data survived.

That is persistence in a form you can actually observe.

Saving is a state transition

Imagine the file currently contains:

[
  {"name": "Nova", "score": 850}
]

Your program loads it and then adds Maya in memory:

players.append({"name": "Maya", "score": 960})

At this moment:

MEMORY
Nova
Maya

DISK
Nova

The two representations disagree.

Only after:

save_players(players)

does the disk state catch up.

That is why "I added the player" and "the player is saved" are different claims.

Crashes expose the gap

Suppose the program does this:

load
add player
crash
save never runs

The new player may have existed in memory for several seconds and still be absent after restart.

The bug is not that JSON forgot. The save transition never completed.

That is a more useful diagnosis.

External files are inputs too

A file can be missing, malformed, empty, stale, or contain unexpected fields.

Your Python source can be unchanged while behavior changes because the external data changed.

Create three controlled cases:

1. valid players.json;
2. missing players.json;
3. malformed players.json.

For each case, record:

file state:
what load_players() does:
visible output/error:
what evidence identifies the cause:

If the program handles a missing file by returning [], explain why that behavior is acceptable for this application.

Do not turn every failure into "catch the exception and ignore it." Sometimes an error should remain visible because hiding it would make the data loss worse.

CSV and JSON are representations, not the data itself

The same roster might be represented as CSV:

name,score
Nova,850
Maya,960

or JSON:

[
  {"name": "Nova", "score": 850},
  {"name": "Maya", "score": 960}
]

The logical information is similar. The representation is different.

JSON preserves nested structures and explicit field names naturally. CSV is often convenient for simple rows and columns.

Choose based on the shape of the data, not because one format looks more technical.

Track the source of truth

For the roster from Lesson 4, answer these at four moments:

Immediately after startup

Which state is authoritative: disk or memory?

After adding a player but before saving

Which copy contains the newest state?

Immediately after saving

Should the two copies agree?

After manually editing the JSON while the program is still running

Which copy is the program currently using?

There is no universal answer that "the file is always the truth" or "memory is always the truth." It depends on the architecture and the moment.

The rule worth keeping

When persistent data looks wrong, ask two questions separately:

What is in memory right now?

What is actually on disk right now?

Do not assume they match.

The interface may show one reality while the storage layer contains another.

By now you should recognize the pattern: the visible layer is not the whole system.

Run the code to see output.