FreeCampus Python

Work Reliably in Colab and Jupyter

Build a readable practice notebook, diagnose stale output and hidden runtime state, then prove the notebook works from a clean top-to-bottom run.
python-foundations get-started notebooks reproducibility
Open in Colab
  • Level: Beginner
  • Estimated time: 2.5–4 hours
  • You will learn: Keep the saved notebook, live Python runtime, cell execution order, and displayed output consistent enough for a clean rerun.
  • Practice in: Google Colab or JupyterLab

Open this lesson in Google Colab

A notebook places explanation, code, and output close together. That makes it a friendly learning environment—and makes it possible to create a convincing page whose visible cells do not reproduce the visible result. This lesson builds a Python Learning Lab notebook that another person can restart and run from top to bottom.

NoteQuestions to answer
  • What is saved in a notebook document, and what exists only in the live runtime?
  • Why can cell order differ from the order shown on the page?
  • How can displayed output become stale?
  • What does restart-and-run-all actually test?
  • Which notebook files and information should you save, download, or avoid sharing?

1. Separate the document from the runtime

A notebook interface brings several things together:

Part What it is What can happen to it
Notebook document Saved cells, their order, metadata, and possibly stored output Can be renamed, copied, downloaded, or shared
Code cell Editable Python source inside the document Can be changed without being run
Markdown cell Formatted explanation, headings, links, and predictions Does not execute as Python
Runtime or kernel The live Python process that executes code Can disconnect, restart, or remember hidden state
Displayed output A record shown beneath a cell Can remain visible after source changes
Runtime file A file created on the current remote or local machine May disappear when a hosted runtime resets

The notebook page and the Python process are related but not identical. Saving a notebook does not keep a hosted runtime alive forever. Restarting a runtime does not normally delete the saved source cells. Editing a cell does not automatically rerun it.

The saved notebook supplies cells to a temporary runtime, which returns output that the page displays.

flowchart LR
  A[Saved notebook document] --> B[Code cell source]
  B --> C[Live Python runtime]
  C --> D[Displayed output]
  A --> E[Markdown explanations]
  C --> F[Temporary runtime state]
  F -. lost on restart .-> G[Clean runtime]

In Google Colab, make or save a copy you control before treating a shared notebook as your work record. In JupyterLab, confirm the file is inside the folder you intend to preserve. Give it the clear name first_notebook.ipynb.

2. Build a notebook that explains its own run

Use four cells.

Cell 1 — Markdown

# Python Learning Lab

Prediction: the next code cell will display three status lines in source order.

Cell 2 — Python

print("Python Learning Lab")
print("Status: ready")
print("Next step: predict before running")

Cell 3 — Markdown

## Observation

Record all three observed lines and explain which source call produced each one.

Cell 4 — Python experiment

print("Python Learning Lab")
print("Status: checked")
print("Next step: predict before running")

The notebook should tell a future reader what question the code answers. A page of unlabeled code and old output is not yet a learning record.

Markdown is part of the artifact

Use Markdown headings to expose structure rather than decorating every sentence. A useful notebook can be scanned for:

  • goal;
  • prediction;
  • original source;
  • observed output;
  • controlled experiment;
  • repair evidence; and
  • conclusion.

Do not place Python source inside a Markdown cell and expect it to run. Do not place a prose heading inside a code cell and expect Python to treat it as page structure.

Checkpoint: identify notebook parts

3. Cell position is not execution history

A notebook lets you run cell 4 before cell 2. The page order remains 1, 2, 3, 4, but runtime history follows the order in which you pressed Run.

This pair previews assignment, which Unit 1 teaches formally. For this notebook diagnosis, understand only that the first cell creates the name status in the current runtime and the second tries to display its current value.

Visible Cell A

status = "ready"

Visible Cell B

print(status)

A fresh runtime that runs B before A raises NameError because status has not been created there. Run A and then B; the output becomes ready.

Now add a third cell later on the page:

status = "checked"

If you run the third cell and then return to run B, B displays checked even though the visible assignment above it still says ready. The result depends on runtime history that the top-to-bottom page does not reveal.

Use a trace table:

Action order Cell run Runtime state after the action Output
1 status = "ready" status refers to ready none
2 status = "checked" status now refers to checked none
3 print(status) still checked checked

The notebook is not random. It followed the actual execution order. The page is misleading because that history is not the order a fresh reader will use.

A clean top-to-bottom trace

Restart the runtime. Now run:

status = "ready"

then:

print(status)

then:

status = "checked"

then:

print(status)

Expected output sequence:

ready
checked

Every dependency now appears before the cell that uses it.

4. Stale output can tell a false story

Suppose a cell originally contains:

print("Status: ready")

You run it and see:

Status: ready

Then you edit the source to:

print("Status: checked")

but do not rerun. Some notebook interfaces keep the old Status: ready output visible. A screenshot would show new source beside old evidence.

Before trusting a notebook:

  1. mark any edited-but-not-run cell;
  2. run the changed cell and inspect new output;
  3. restart the runtime;
  4. run every code cell from the top in page order;
  5. confirm no cell fails or depends on a value created later; and
  6. save the notebook after the clean run.

A stored output is a useful record only when you know which source and runtime state produced it.

Checkpoint: reconstruct execution history

5. Restart and run all is an experiment

“Restart and run all” is not a ritual that repairs every notebook. It tests a specific claim:

The visible notebook contains every required step in an order that succeeds from an empty runtime.

The experiment has a baseline and observable result:

  1. save your current source cells;
  2. restart or disconnect and reconnect to obtain an empty runtime;
  3. run cells from the first code cell to the last without manually jumping ahead;
  4. stop at the first error;
  5. record the cell, exception, and missing dependency;
  6. repair the notebook’s visible order or source;
  7. restart again; and
  8. repeat until a clean run succeeds.

If you repair the runtime by manually running a later setup cell first, the page still fails its clean-run contract. Move or rewrite the dependency so page order works.

Read execution indicators carefully

Many notebook interfaces show an execution count or running indicator beside a code cell. Counts can reveal that lower cells ran earlier, but do not rely on one interface’s exact appearance. The strongest test is a restart and complete run, not a tidy-looking sequence of old numbers.

Interrupt work that will not finish

A cell can remain busy because it is doing a large task or because the code does not stop. Use the interface’s interrupt or stop action rather than refreshing repeatedly. Preserve the source and note which cell was running. Unit 4 teaches loop termination; Unit 8 teaches systematic debugging. Unit 0 asks only that you know the runtime can be interrupted and restarted.

Do not use this deliberately endless example as normal practice; read its shape only:

while True:
    keep_working_forever

The text fence prevents the generated notebook from running it. Later you will learn what a loop condition means.

6. Save the right artifact and share it carefully

A hosted runtime may disappear. Preserve:

  • the notebook document in a durable location you control;
  • important input files or instructions for recreating them;
  • the environment or package information when external packages become relevant; and
  • the clean-run evidence in Markdown.

Do not assume a notebook saved in a shared course location belongs to your account. Make your own copy or download it. Reopen that copy before deleting the original session.

Before sharing, inspect:

  • Markdown cells for names, email addresses, class identifiers, or private notes;
  • source cells for passwords, tokens, paths containing personal names, or private URLs;
  • output cells for data that the cleaned source no longer shows; and
  • notebook metadata and attached files when the context is sensitive.

Deleting a secret from the current source is not enough if an old output cell still displays it. Rotate any real credential that was exposed.

Choose a notebook, script, or published page for its job

Artifact Best fit now Important boundary
Colab/Jupyter notebook Explore, predict, explain, and display nearby output Runtime state can be hidden and hosted files can be temporary
.py script Run saved source from top to bottom Rich prose and old output do not live beside the source
Quarto page Publish structured teaching or documentation Rendering is not the same as the learner’s live runtime

Unit 10 moves reusable behavior into modules and project structure. Unit 15 builds published documentation. Here, use a notebook as an honest lab record.

Checkpoint: prove a clean notebook

7. Lab: prove first_notebook.ipynb from a clean runtime

Create or rename a notebook to first_notebook.ipynb. Build these sections:

  1. # Python Learning Lab
  2. a Markdown prediction for the exact three-line baseline;
  3. one baseline code cell with the three print(...) calls;
  4. a Markdown observation that maps source lines to output lines;
  5. a controlled experiment cell that changes only ready to checked;
  6. a Markdown comparison naming the changed and stable output;
  7. two state cells: one creates status = "ready", and the next displays it;
  8. a Markdown note explaining that assignment is a Unit 1 preview; and
  9. a final clean-run record.

Then create one hidden-state failure deliberately:

  1. run the state-creation cell;
  2. change the live value in a temporary lower cell to checked;
  3. rerun the display cell and observe the surprising result;
  4. delete the temporary cell;
  5. restart the runtime; and
  6. run all visible cells from the top.

Completion evidence:

Notebook filename:
Clean-run action used:
First code cell result:
Controlled experiment result:
State display result after restart:
Any warning or failure and its repair:
Durable save/download location:
Hint: repair the page, not only the runtime

After exposing hidden state, remove the temporary mutation and make sure every visible use has its required creation above it. Then restart again; do not rely on manually running a cell out of order.

Show one possible notebook order

Use this sequence:

  1. Markdown title and prediction.
  2. Baseline program:
print("Python Learning Lab")
print("Status: ready")
print("Next step: predict before running")
  1. Markdown observation.
  2. Controlled experiment:
print("Python Learning Lab")
print("Status: checked")
print("Next step: predict before running")
  1. Markdown comparison.
  2. State preview:
status = "ready"
  1. Display:
print(status)
  1. Markdown clean-run record.

Restart and run all. The baseline and controlled experiment each display their three expected lines; the final display is ready. Save after this clean run.

Key points

  • The notebook document, live runtime, displayed output, and temporary files have different lifecycles.
  • Page position does not prove execution order.
  • Editing source does not refresh old output.
  • Restart-and-run-all tests whether visible dependencies succeed from an empty runtime in page order.
  • Repair the notebook’s source or order instead of manually recreating hidden state.
  • Save important notebooks and files deliberately, and inspect source, output, metadata, and attachments before sharing.

References

Back to top