Protocol
Scientific Python That Reproduces
Build a small dataset-inspection CLI. Choose and justify whether invalid records reject the file or enter a separate error report; never silently coerce them.
20–35 active hours60–90 min sessionsBeginner6 milestones
Scientific Python · first work block preview · 60–90 minutes
Names, mutation and reproducible execution
Predict, run, explain and modify the four short programs below. Use Python 3 locally; record python --version with your outputs.
Session boundary: work for 60–90 minutes, then keep your outputs and next question. Resume unfinished work next time.
Ready? You can run a Python file and use functions, loops and files. Need help? Open the relevant Python documentation ↗
Do this first: copy program 1 into names.py. Write its predicted output in predictions.md before running python names.py. Repeat with a separate file for each program.
1. Aliasing: two names, one list
a = [1, 2]
b = a
b.append(3)
print(a)
print(b)Predict both lines before running. Are a and b two lists? Modify the program so changing b no longer changes a.
2. Mutation across function calls
def collect(value, items=[]):
items.append(value)
return items
print(collect("first"))
print(collect("second"))Predict both calls. Explain when the default list is created. Repair it so each omitted argument starts a new list.
3. Scope and rebinding
value = 10
def change():
value = 20
return value
print(change())
print(value)Predict both lines and explain which name each refers to. Modify change to accept and return a value explicitly.
4. Floating-point approximation
from decimal import Decimal
print(0.1 + 0.2 == 0.3)
print(Decimal("0.1") + Decimal("0.2") == Decimal("0.3"))Predict both comparisons. Save the outputs and explain why decimal strings matter. Create another small counterexample yourself.
Explain, then create: reconcile every prediction with the observed output. Finally write your own aliasing example without looking at the starter. These are practice examples, not model answers to a review.
Enough for today: stop after 60–90 minutes. Save your files and a note naming the next unresolved question. If the task is unfinished, resume it in your next block; only mark the task complete when its output is ready.
Keep: Keep predictions.md, four .py files and outputs.txt. Explain each prediction, the actual output and any difference.
The whole protocol takes roughly 20–35 active hours. Each task may take several work blocks. Recording practice never awards technical mastery.
Project criteria and evidence, when you are ready →Mastery contract
Core protocol · Standard 1.0 · Build a small dataset-inspection CLI. Choose and justify whether invalid records reject the file or enter a separate error report; never silently coerce them.
Loading your learning records…
Reasoning — not yet passed
Predict all 4 program outputs before execution, trace the state changes, and demonstrate a decimal-arithmetic counterexample with saved outputs.
Reliable implementation — not yet passed
A fresh environment runs the documented command; tests cover empty, malformed, and ordinary input without silent row loss.
Reproducible experiment — not yet passed
Two runs on the same input produce identical data summaries and hashes; malformed input exits nonzero with an actionable message.
Defense and handoff — not yet passed
Defend the schema and error policy, demonstrate one repaired bug, and hand the project to a reviewer who can reproduce its outputs.
All four criteria must pass. Activity completion does not satisfy them.
An independent reviewer reruns your work and varies something you did not rehearse: a fresh input, a different working directory, or a declared edge case.
What you will do
6 milestones · one evolving project
Predict Python behavior
- Learn
- Do
- Explain aliasing, mutation, scope, and floating-point approximation using 4 small programs; predict each output before executing it.
- Save
- Prediction ledger saved before execution, raw outputs, state traces and a floating-point counterexample
- Feeds
- Reasoning
Build the inspector
- Learn
- Do
- Implement a command-line CSV summary tool using the Python standard library; validate column types, report missing rows, and emit JSON plus the input SHA-256.
- Save
- Written schema and error contract committed before the parser, then the CLI emitting JSON plus the input SHA-256
- Feeds
- Reliable implementation
Prove reproducibility
- Learn
- Do
- Run the tool on 3 fixtures including empty and malformed input; compare two clean-environment runs and identify which outputs must match byte for byte.
- Save
- Ordinary, empty and malformed fixtures; two clean-environment runs with identical canonical output and hashes
- Feeds
- Reliable implementation · Reproducible experiment
Write the handoff report
- Do
- Write a 500–900 word technical report linking the reasoning, code, measurements, and limitations; include the project decision below.
- Save
- 500–900 word report defending the schema and error policy, with limitations and the repaired defect
- Feeds
- Defense and handoff
Hand it to a reviewer
- Do
- Assess all 4 mastery criteria against saved artifacts, request an independent review, and repeat each failed criterion on a fresh example.
- Save
- Evidence submission for all four gates; failed gates repeated on a fresh example
- Feeds
- Reasoning · Reliable implementation · Reproducible experiment · Defense and handoff
Pilot decisions are provisional, not external credentials. For an appeal or sensitive artifact, contact your designated pilot operator with the submission ID. Export your assessment history.
Essentials
A reading session alone never satisfies a mastery criterion.
Store source references, assumptions, and artifact paths beside every result.
Keep an untouched check case that differs from the worked example.
Record all attempts, including failures and results that contradict your prediction.
Use the stated comparison conditions; document every deviation before drawing a conclusion.
Protocol guardrails
Do
- +State the expected result before running the comparison.
- +Keep one minimal reproducible failing case when debugging.
- +Record environment versions and the exact command used.
- +Compare explanations with saved intermediate values.
- +Ask a reviewer to challenge the weakest assumption.
Don't
- ×Do not let invalid rows disappear silently; every rejected record is counted or reported.
- ×Do not coerce invalid values into plausible valid ones.
- ×Do not put timestamps or machine-specific paths in the canonical output you compare between runs.
- ×Do not rely on shell history or undocumented manual setup; the reproduction command must work from a clean checkout.
- ×Do not delete failed attempts or the defective version of a repaired bug; they are evidence.
Protocol authorship
Written by NuthinButta as instructional design. The teaching sources are the official references linked in each milestone; the exercises, workload and pass thresholds are ours, not their authors'.