Classes and objects
Measure whether the ThresholdModel class works
Page 4 turns “it ran” into executable checks for the ThresholdModel class with per-instance cutoffs.
1Learn the idea
Read
Make the metric executable
Translate the claim into assertions or a tiny eval harness. The metric to protect is: assert Strict(0.8) and Loose(0.4) disagree on score 0.5. Always record the denominator (how many cases) beside any rate. A percentage without a denominator is marketing, not measurement.
Read
Run the checks
class ThresholdModel:
def __init__(self, name, threshold):
self.threshold=threshold
def predict(self, scores):
return [s>=self.threshold for s in scores]
a,b=ThresholdModel('S',0.8),ThresholdModel('L',0.4)
assert a.predict([0.5])!=b.predict([0.5])
print('instances disagree on 0.5 as expected')
Expected evidence: instances disagree on 0.5 as expected. A passing assertion proves only the behavior it names; broader usefulness still needs the chapter’s full limits.
Read
Say what the metric does not prove
Be explicit: beating the baseline (two handwritten prediction tables before coding the class) on this fixture does not prove behavior under shared mutable class attribute for threshold so instances overwrite each other. Label observations separately from conclusions so the next page inherits honest evidence about the ThresholdModel class.
Read
Lab notebook: denominator discipline
Compute assert Strict(0.8) and Loose(0.4) disagree on score 0.5 with the denominator written beside the rate every time. For this chapter, the evaluation set is intentionally tiny; that is allowed only if you say so in the evidence. Compare against two handwritten prediction tables before coding the class before celebrating.
Add one negative case aimed at shared mutable class attribute for threshold so instances overwrite each other. A suite with only happy cases cannot protect the ThresholdModel class when the characteristic failure appears in review.
Read
Worked judgment
If a check is expensive or flaky, shrink it until it is deterministic on Strict(threshold=0.8), Loose(threshold=0.4), scores=[0.5,0.9]. Flaky green builds teach the team to ignore gates. Record what this page does not prove so security-ops and mastery-ship inherit honest limits.
Read
Why this stage matters for the ThresholdModel class
At the evaluation stage for python-classes, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about Strict(threshold=0.8), Loose(threshold=0.4), scores=(0.5,0.9) that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: two handwritten prediction tables before coding the class.
For this page specifically, success looks like metrics with explicit denominators and a negative case while still centering the user decision to reuse one predict method across two named models with different thresholds. If you cannot point to a file, command, or assertion that proves that for the ThresholdModel class, stay on this page instead of advancing.
Read
Chapter consolidation 1
Return to the python classes scenario and restate what this chapter proved on page validation.mdx. Name one metric, one ownership rule, and one regression test you will keep. Explain how this page connects to the previous page without repeating earlier paragraphs. If you cannot name a falsifier, the chapter is still a story rather than a controlled practice. Write the falsifier as an observable event with a threshold.
Read
Chapter consolidation 2
Return to the python classes scenario and restate what this chapter proved on page validation.mdx. Name one metric, one ownership rule, and one regression test you will keep. Explain how this page connects to the previous page without repeating earlier paragraphs. If you cannot name a falsifier, the chapter is still a story rather than a controlled practice. Write the falsifier as an observable event with a threshold.
Read
Chapter consolidation 3
Return to the python classes scenario and restate what this chapter proved on page validation.mdx. Name one metric, one ownership rule, and one regression test you will keep. Explain how this page connects to the previous page without repeating earlier paragraphs. If you cannot name a falsifier, the chapter is still a story rather than a controlled practice. Write the falsifier as an observable event with a threshold.
Read
Extra mastery block
For python-classes, write a transfer example that differs in one constraint from the chapter scenario. Keep the quality bar fixed. Explain which check still applies.
Go deeper
Before you start
Why this matters
Write one independent check that would catch a fake pass for this lab. Prefer a check tied to assert Strict(0.8) and Loose(0.4) disagree on score 0.5 over a check that only asserts “no exception.”
In the wild
See how this idea shows up as a product and a company — then come back to the lesson. Skills transfer across vendors.
Related lessons
Check your understanding
Page assessment
Answer from memory. Completion is saved from this evidence, not from opening the next page.
All responses are required.