Classes and objects
Debug shared mutable class attribute for threshold so instances overwrite each other in the Threshol
Page 5 reproduces and repairs the characteristic failure of the ThresholdModel class with per-instance cutoffs: shared mutable class attribute for threshold so instances overwrite each other.
1Learn the idea
Read
Reproduce before you repair
Do not start with a speculative fix for the ThresholdModel class. Force the failure on purpose, save the before output, then change one cause at a time. Retries are allowed only for transient conditions—not for bad input that will fail forever on python-classes.
Read
Force the failure
class ThresholdModel:
def __init__(self, name, threshold):
self.name=name; self.threshold=threshold # instance attr, not class attr
try:
ThresholdModel('Bad', 1.5)
except Exception as e:
print(type(e).__name__)
Read
demonstrate class-attr bug avoided
print({'threshold_storage':'instance'})
Expected evidence: **ValueError or explicit instance storage note**. If you cannot reproduce on demand, you do not yet control the failure mode for `python-classes`.
Read
Repair with a reviewable diff
After repair, rerun the exact reproduction command. Keep the failing fixture as a regression seed for the observability page. For the ThresholdModel class with per-instance cutoffs, remember the claim you are restoring: strict and loose instances return different Booleans for the same score list.
Read
Lab notebook: reproduce on command
Store a one-command reproduction for: shared mutable class attribute for threshold so instances overwrite each other. The command should use Strict(threshold=0.8), Loose(threshold=0.4), scores=[0.5,0.9] or a minimal mutant of it. Paste the failing output into notes/failure-before.txt (or your shell scrollback as copied text). After the fix, paste notes/failure-after.txt and keep both.
Retries belong only on transient faults. If the failure is bad input, a bad allowlist, or a logic bug in the ThresholdModel class, retrying will amplify cost without repairing trust around reuse one predict method across two named models with different thresholds.
Read
Worked judgment
Classify the failure as prevent, detect, contain, or recover—using this lab’s language, not a generic poster. For python-classes, the first fix should usually be detect+prevent at the boundary, because shared mutable class attribute for threshold so instances overwrite each other is cheaper to stop early than to explain in production prose.
Read
Why this stage matters for the ThresholdModel class
At the debugging 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 before/after evidence for the characteristic failure 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.
Go deeper
Before you start
Why this matters
Describe the smallest fixture that triggers shared mutable class attribute for threshold so instances overwrite each other. Predict the first visible symptom (exception, wrong label, silent empty success). You will compare that prediction with the reproduction below.
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.