When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.
Python graphlib.TopologicalSorter turns prerequisite relationships among hashable nodes into a valid execution order. Mastery means modelling edges in the correct predecessor direction, separating readiness from completion, using prepare, get_ready and done as one protocol, understanding how cycles block only part of a graph, coordinating workers without inventing false parallel guarantees, and choosing a simple static order whenever dynamic scheduling would add more machinery than value. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.
The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.
Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.
Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.
Find your next learning step
Choose the route that matches the present difficulty. Use the complete index for a systematic course.
Build the model
Chapters 1-4 . Begin here, then continue after the learner can predict, verify and explain.
Use the core tools
Chapters 5-8 . Begin here, then continue after the learner can predict, verify and explain.
Handle boundaries
Chapters 9-12 . Begin here, then continue after the learner can predict, verify and explain.
Debug and verify
Chapters 13-16 . Begin here, then continue after the learner can predict, verify and explain.
Transfer with judgment
Chapters 17-20 . Begin here, then continue after the learner can predict, verify and explain.
Open the full chapter index . Jump to capstone practice . Use the How Studying Works hub . Read the official documentation
Complete chapter index
Chapters 1-4 . Build the model
Chapters 5-8 . Use the core tools
Chapters 9-12 . Handle boundaries
Chapters 13-16 . Debug and verify
A topological order places every predecessor before each node that depends on it. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is treating topological order as alphabetical sorting. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the A topological order respects prerequisites chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating topological order as alphabetical sorting. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
from graphlib import TopologicalSorter
graph={'submit':{'review'},'review':{'draft'},'draft':set()}
print(tuple(TopologicalSorter(graph).static_order()))Explained result. The only valid sequence is draft, review, submit. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework plan. Predict the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A topological order places every predecessor before each node that depends on it.” Apply this procedure: State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The only valid sequence is draft, review, submit. For the homework plan, add one near-miss that exposes treating topological order as alphabetical sorting. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science project. Contrast the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A topological order places every predecessor before each node that depends on it.” Apply this procedure: State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The only valid sequence is draft, review, submit. For the science project, add one near-miss that exposes treating topological order as alphabetical sorting. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA event. Stress-test the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A topological order places every predecessor before each node that depends on it.” Apply this procedure: State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The only valid sequence is draft, review, submit. For the CCA event, add one near-miss that exposes treating topological order as alphabetical sorting. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: coding build. Explain the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A topological order places every predecessor before each node that depends on it.” Apply this procedure: State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The only valid sequence is draft, review, submit. For the coding build, add one near-miss that exposes treating topological order as alphabetical sorting. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers treating topological order as alphabetical sorting.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from A topological order respects prerequisites?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating topological order as alphabetical sorting be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny cycle laboratory with three tasks accidentally depend on one another and block progress. Include one ordinary case, one boundary and one deliberate failure caused by treating topological order as alphabetical sorting. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A topological order places every predecessor before each node that depends on it. It shows a trace, not only a final value. The ordinary case should demonstrate “The only valid sequence is draft, review, submit.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A topological order respects prerequisites, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reversing edges and obtaining a plausible but backwards plan. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the The mapping points from node to predecessors chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reversing edges and obtaining a plausible but backwards plan. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
graph={'test':{'build'},'build':{'source'},'source':set()}Explained result. source must be ready before build, and build before test. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA event. Contrast the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it.” Apply this procedure: State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: source must be ready before build, and build before test. For the CCA event, add one near-miss that exposes reversing edges and obtaining a plausible but backwards plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: coding build. Stress-test the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it.” Apply this procedure: State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: source must be ready before build, and build before test. For the coding build, add one near-miss that exposes reversing edges and obtaining a plausible but backwards plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: family errand. Explain the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it.” Apply this procedure: State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: source must be ready before build, and build before test. For the family errand, add one near-miss that exposes reversing edges and obtaining a plausible but backwards plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: cycle laboratory. Transfer the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it.” Apply this procedure: State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: source must be ready before build, and build before test. For the cycle laboratory, add one near-miss that exposes reversing edges and obtaining a plausible but backwards plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reversing edges and obtaining a plausible but backwards plan.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from The mapping points from node to predecessors?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reversing edges and obtaining a plausible but backwards plan be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny worker queue with a coordinator dispatches ready jobs and records completion centrally. Include one ordinary case, one boundary and one deliberate failure caused by reversing edges and obtaining a plausible but backwards plan. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it. It shows a trace, not only a final value. The ordinary case should demonstrate “source must be ready before build, and build before test.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For The mapping points from node to predecessors, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Nodes are stored in sets and mappings, so immutable strings, numbers, tuples and other hashable objects work while lists do not. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using mutable lists as task identities. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Nodes must be hashable chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using mutable lists as task identities. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
from graphlib import TopologicalSorter
TopologicalSorter({('write',1):set()})Explained result. The tuple is a valid hashable node identity. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: family errand. Stress-test the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Nodes are stored in sets and mappings, so immutable strings, numbers, tuples and other hashable objects work while lists do not.” Apply this procedure: State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The tuple is a valid hashable node identity. For the family errand, add one near-miss that exposes using mutable lists as task identities. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: cycle laboratory. Explain the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Nodes are stored in sets and mappings, so immutable strings, numbers, tuples and other hashable objects work while lists do not.” Apply this procedure: State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The tuple is a valid hashable node identity. For the cycle laboratory, add one near-miss that exposes using mutable lists as task identities. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: worker queue. Transfer the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Nodes are stored in sets and mappings, so immutable strings, numbers, tuples and other hashable objects work while lists do not.” Apply this procedure: State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The tuple is a valid hashable node identity. For the worker queue, add one near-miss that exposes using mutable lists as task identities. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: design decision. Predict the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Nodes are stored in sets and mappings, so immutable strings, numbers, tuples and other hashable objects work while lists do not.” Apply this procedure: State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The tuple is a valid hashable node identity. For the design decision, add one near-miss that exposes using mutable lists as task identities. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using mutable lists as task identities.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Nodes must be hashable?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using mutable lists as task identities be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny design decision with a fixed sequential order is compared with dynamic multi-worker scheduling. Include one ordinary case, one boundary and one deliberate failure caused by using mutable lists as task identities. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Nodes are stored in sets and mappings, so immutable strings, numbers, tuples and other hashable objects work while lists do not. It shows a trace, not only a final value. The ordinary case should demonstrate “The tuple is a valid hashable node identity.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Nodes must be hashable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Nodes must be hashable, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is mixing graph modelling with execution after sorting begins. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Construct from a mapping or add incrementally chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mixing graph modelling with execution after sorting begins. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ts=TopologicalSorter(); ts.add('draft'); ts.add('review','draft')Explained result. The incremental graph records draft as the predecessor of review. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: worker queue. Explain the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation.” Apply this procedure: State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The incremental graph records draft as the predecessor of review. For the worker queue, add one near-miss that exposes mixing graph modelling with execution after sorting begins. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: design decision. Transfer the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation.” Apply this procedure: State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The incremental graph records draft as the predecessor of review. For the design decision, add one near-miss that exposes mixing graph modelling with execution after sorting begins. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework plan. Predict the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation.” Apply this procedure: State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The incremental graph records draft as the predecessor of review. For the homework plan, add one near-miss that exposes mixing graph modelling with execution after sorting begins. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science project. Contrast the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation.” Apply this procedure: State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The incremental graph records draft as the predecessor of review. For the science project, add one near-miss that exposes mixing graph modelling with execution after sorting begins. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers mixing graph modelling with execution after sorting begins.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Construct from a mapping or add incrementally?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mixing graph modelling with execution after sorting begins be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework plan with revision tasks depend on earlier notes and prerequisite examples. Include one ordinary case, one boundary and one deliberate failure caused by mixing graph modelling with execution after sorting begins. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation. It shows a trace, not only a final value. The ordinary case should demonstrate “The incremental graph records draft as the predecessor of review.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Construct from a mapping or add incrementally, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Adding the same node again combines new predecessors with those already recorded rather than replacing the earlier set. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming a later add erases earlier prerequisites. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Repeated add calls union dependencies chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming a later add erases earlier prerequisites. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ts=TopologicalSorter(); ts.add('publish','edit'); ts.add('publish','fact-check')Explained result. publish depends on both edit and fact-check. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework plan. Transfer the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Adding the same node again combines new predecessors with those already recorded rather than replacing the earlier set.” Apply this procedure: State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: publish depends on both edit and fact-check. For the homework plan, add one near-miss that exposes assuming a later add erases earlier prerequisites. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science project. Predict the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Adding the same node again combines new predecessors with those already recorded rather than replacing the earlier set.” Apply this procedure: State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: publish depends on both edit and fact-check. For the science project, add one near-miss that exposes assuming a later add erases earlier prerequisites. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA event. Contrast the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Adding the same node again combines new predecessors with those already recorded rather than replacing the earlier set.” Apply this procedure: State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: publish depends on both edit and fact-check. For the CCA event, add one near-miss that exposes assuming a later add erases earlier prerequisites. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: coding build. Stress-test the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Adding the same node again combines new predecessors with those already recorded rather than replacing the earlier set.” Apply this procedure: State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: publish depends on both edit and fact-check. For the coding build, add one near-miss that exposes assuming a later add erases earlier prerequisites. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming a later add erases earlier prerequisites.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Repeated add calls union dependencies?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming a later add erases earlier prerequisites be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science project with data collection must finish before graphs and conclusions can begin. Include one ordinary case, one boundary and one deliberate failure caused by assuming a later add erases earlier prerequisites. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Adding the same node again combines new predecessors with those already recorded rather than replacing the earlier set. It shows a trace, not only a final value. The ordinary case should demonstrate “publish depends on both edit and fact-check.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Repeated add calls union dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Repeated add calls union dependencies, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A predecessor named in add is added to the graph even when it never receives its own explicit add call. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is expecting an undeclared prerequisite to be ignored. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Mentioned predecessors become nodes chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting an undeclared prerequisite to be ignored. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ts=TopologicalSorter(); ts.add('submit','draft')Explained result. Both submit and draft are graph nodes, with draft initially ready. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA event. Predict the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A predecessor named in add is added to the graph even when it never receives its own explicit add call.” Apply this procedure: State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Both submit and draft are graph nodes, with draft initially ready. For the CCA event, add one near-miss that exposes expecting an undeclared prerequisite to be ignored. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: coding build. Contrast the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A predecessor named in add is added to the graph even when it never receives its own explicit add call.” Apply this procedure: State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Both submit and draft are graph nodes, with draft initially ready. For the coding build, add one near-miss that exposes expecting an undeclared prerequisite to be ignored. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: family errand. Stress-test the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A predecessor named in add is added to the graph even when it never receives its own explicit add call.” Apply this procedure: State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Both submit and draft are graph nodes, with draft initially ready. For the family errand, add one near-miss that exposes expecting an undeclared prerequisite to be ignored. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: cycle laboratory. Explain the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A predecessor named in add is added to the graph even when it never receives its own explicit add call.” Apply this procedure: State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Both submit and draft are graph nodes, with draft initially ready. For the cycle laboratory, add one near-miss that exposes expecting an undeclared prerequisite to be ignored. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers expecting an undeclared prerequisite to be ignored.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Mentioned predecessors become nodes?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting an undeclared prerequisite to be ignored be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA event with venue confirmation unlocks printing and logistics tasks. Include one ordinary case, one boundary and one deliberate failure caused by expecting an undeclared prerequisite to be ignored. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A predecessor named in add is added to the graph even when it never receives its own explicit add call. It shows a trace, not only a final value. The ordinary case should demonstrate “Both submit and draft are graph nodes, with draft initially ready.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Mentioned predecessors become nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Mentioned predecessors become nodes, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
prepare validates the graph and establishes internal readiness state before get_ready and done are used. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is trying to add new work after preparation. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the prepare freezes the graph for scheduling chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on trying to add new work after preparation. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ts=TopologicalSorter({'b':{'a'},'a':set()}); ts.prepare()Explained result. The sorter is ready to report initial nodes and should no longer receive add calls. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: family errand. Contrast the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare validates the graph and establishes internal readiness state before get_ready and done are used.” Apply this procedure: State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter is ready to report initial nodes and should no longer receive add calls. For the family errand, add one near-miss that exposes trying to add new work after preparation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: cycle laboratory. Stress-test the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare validates the graph and establishes internal readiness state before get_ready and done are used.” Apply this procedure: State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter is ready to report initial nodes and should no longer receive add calls. For the cycle laboratory, add one near-miss that exposes trying to add new work after preparation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: worker queue. Explain the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare validates the graph and establishes internal readiness state before get_ready and done are used.” Apply this procedure: State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter is ready to report initial nodes and should no longer receive add calls. For the worker queue, add one near-miss that exposes trying to add new work after preparation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: design decision. Transfer the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare validates the graph and establishes internal readiness state before get_ready and done are used.” Apply this procedure: State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter is ready to report initial nodes and should no longer receive add calls. For the design decision, add one near-miss that exposes trying to add new work after preparation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers trying to add new work after preparation.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from prepare freezes the graph for scheduling?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing trying to add new work after preparation be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny coding build with generated files depend on source and configuration steps. Include one ordinary case, one boundary and one deliberate failure caused by trying to add new work after preparation. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: prepare validates the graph and establishes internal readiness state before get_ready and done are used. It shows a trace, not only a final value. The ordinary case should demonstrate “The sorter is ready to report initial nodes and should no longer receive add calls.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For prepare freezes the graph for scheduling, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
After preparation, get_ready reports nodes whose predecessors have been marked done and removes them from the immediately ready pool. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling get_ready repeatedly without completing dispatched work. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the get_ready returns currently unblocked nodes chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling get_ready repeatedly without completing dispatched work. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ready=ts.get_ready()Explained result. The returned tuple is the current dispatch batch; another call may be empty until done is reported. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: worker queue. Stress-test the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After preparation, get_ready reports nodes whose predecessors have been marked done and removes them from the immediately ready pool.” Apply this procedure: State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The returned tuple is the current dispatch batch; another call may be empty until done is reported. For the worker queue, add one near-miss that exposes calling get_ready repeatedly without completing dispatched work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: design decision. Explain the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After preparation, get_ready reports nodes whose predecessors have been marked done and removes them from the immediately ready pool.” Apply this procedure: State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The returned tuple is the current dispatch batch; another call may be empty until done is reported. For the design decision, add one near-miss that exposes calling get_ready repeatedly without completing dispatched work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework plan. Transfer the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After preparation, get_ready reports nodes whose predecessors have been marked done and removes them from the immediately ready pool.” Apply this procedure: State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The returned tuple is the current dispatch batch; another call may be empty until done is reported. For the homework plan, add one near-miss that exposes calling get_ready repeatedly without completing dispatched work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science project. Predict the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After preparation, get_ready reports nodes whose predecessors have been marked done and removes them from the immediately ready pool.” Apply this procedure: State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The returned tuple is the current dispatch batch; another call may be empty until done is reported. For the science project, add one near-miss that exposes calling get_ready repeatedly without completing dispatched work. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling get_ready repeatedly without completing dispatched work.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from get_ready returns currently unblocked nodes?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling get_ready repeatedly without completing dispatched work be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family errand with several independent stops become ready after one shared preparation. Include one ordinary case, one boundary and one deliberate failure caused by calling get_ready repeatedly without completing dispatched work. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: After preparation, get_ready reports nodes whose predecessors have been marked done and removes them from the immediately ready pool. It shows a trace, not only a final value. The ordinary case should demonstrate “The returned tuple is the current dispatch batch; another call may be empty until done is reported.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for get_ready returns currently unblocked nodes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For get_ready returns currently unblocked nodes, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A node passed to done must previously have been returned by get_ready and not already marked done. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is marking a prerequisite done merely because it exists. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the done records completion rather than dispatch chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on marking a prerequisite done merely because it exists. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
for node in ts.get_ready():
run(node); ts.done(node)Explained result. Each completion signal can unlock dependent nodes. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework plan. Explain the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A node passed to done must previously have been returned by get_ready and not already marked done.” Apply this procedure: State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Each completion signal can unlock dependent nodes. For the homework plan, add one near-miss that exposes marking a prerequisite done merely because it exists. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science project. Transfer the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A node passed to done must previously have been returned by get_ready and not already marked done.” Apply this procedure: State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Each completion signal can unlock dependent nodes. For the science project, add one near-miss that exposes marking a prerequisite done merely because it exists. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA event. Predict the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A node passed to done must previously have been returned by get_ready and not already marked done.” Apply this procedure: State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Each completion signal can unlock dependent nodes. For the CCA event, add one near-miss that exposes marking a prerequisite done merely because it exists. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: coding build. Contrast the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A node passed to done must previously have been returned by get_ready and not already marked done.” Apply this procedure: State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Each completion signal can unlock dependent nodes. For the coding build, add one near-miss that exposes marking a prerequisite done merely because it exists. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers marking a prerequisite done merely because it exists.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from done records completion rather than dispatch?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing marking a prerequisite done merely because it exists be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny cycle laboratory with three tasks accidentally depend on one another and block progress. Include one ordinary case, one boundary and one deliberate failure caused by marking a prerequisite done merely because it exists. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A node passed to done must previously have been returned by get_ready and not already marked done. It shows a trace, not only a final value. The ordinary case should demonstrate “Each completion signal can unlock dependent nodes.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for done records completion rather than dispatch, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For done records completion rather than dispatch, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is forcing an artificial order and calling it a graph requirement. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Several nodes can be ready together chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on forcing an artificial order and calling it a graph requirement. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
graph={'write':set(),'draw':set(),'assemble':{'write','draw'}}Explained result. write and draw can be ready together; assemble waits for both. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA event. Transfer the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch.” Apply this procedure: State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: write and draw can be ready together; assemble waits for both. For the CCA event, add one near-miss that exposes forcing an artificial order and calling it a graph requirement. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: coding build. Predict the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch.” Apply this procedure: State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: write and draw can be ready together; assemble waits for both. For the coding build, add one near-miss that exposes forcing an artificial order and calling it a graph requirement. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: family errand. Contrast the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch.” Apply this procedure: State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: write and draw can be ready together; assemble waits for both. For the family errand, add one near-miss that exposes forcing an artificial order and calling it a graph requirement. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: cycle laboratory. Stress-test the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch.” Apply this procedure: State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: write and draw can be ready together; assemble waits for both. For the cycle laboratory, add one near-miss that exposes forcing an artificial order and calling it a graph requirement. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers forcing an artificial order and calling it a graph requirement.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Several nodes can be ready together?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing forcing an artificial order and calling it a graph requirement be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny worker queue with a coordinator dispatches ready jobs and records completion centrally. Include one ordinary case, one boundary and one deliberate failure caused by forcing an artificial order and calling it a graph requirement. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch. It shows a trace, not only a final value. The ordinary case should demonstrate “write and draw can be ready together; assemble waits for both.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Several nodes can be ready together, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 11 OF 20 . Handle boundaries
11. Readiness does not promise safe parallel code
The graph expresses prerequisite order, not thread safety, resource independence or permission to run every ready task concurrently. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is equating no edge with no shared-state conflict. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Readiness does not promise safe parallel code chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on equating no edge with no shared-state conflict. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
# Add a separate resource policy before dispatching ready jobsExplained result. Two ready tasks may still require the same file, device or rate-limited service. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: family errand. Predict the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The graph expresses prerequisite order, not thread safety, resource independence or permission to run every ready task concurrently.” Apply this procedure: State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Two ready tasks may still require the same file, device or rate-limited service. For the family errand, add one near-miss that exposes equating no edge with no shared-state conflict. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: cycle laboratory. Contrast the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The graph expresses prerequisite order, not thread safety, resource independence or permission to run every ready task concurrently.” Apply this procedure: State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Two ready tasks may still require the same file, device or rate-limited service. For the cycle laboratory, add one near-miss that exposes equating no edge with no shared-state conflict. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: worker queue. Stress-test the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The graph expresses prerequisite order, not thread safety, resource independence or permission to run every ready task concurrently.” Apply this procedure: State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Two ready tasks may still require the same file, device or rate-limited service. For the worker queue, add one near-miss that exposes equating no edge with no shared-state conflict. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: design decision. Explain the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The graph expresses prerequisite order, not thread safety, resource independence or permission to run every ready task concurrently.” Apply this procedure: State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Two ready tasks may still require the same file, device or rate-limited service. For the design decision, add one near-miss that exposes equating no edge with no shared-state conflict. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers equating no edge with no shared-state conflict.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Readiness does not promise safe parallel code?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing equating no edge with no shared-state conflict be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny design decision with a fixed sequential order is compared with dynamic multi-worker scheduling. Include one ordinary case, one boundary and one deliberate failure caused by equating no edge with no shared-state conflict. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The graph expresses prerequisite order, not thread safety, resource independence or permission to run every ready task concurrently. It shows a trace, not only a final value. The ordinary case should demonstrate “Two ready tasks may still require the same file, device or rate-limited service.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Readiness does not promise safe parallel code, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Readiness does not promise safe parallel code, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 12 OF 20 . Handle boundaries
12. is_active describes unfinished schedulable work
is_active, and boolean testing of the sorter, stays true while progress remains possible or dispatched nodes have not been marked done. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using an empty get_ready tuple alone as proof the workflow is finished. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the is_active describes unfinished schedulable work chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using an empty get_ready tuple alone as proof the workflow is finished. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
while ts:
for node in ts.get_ready(): dispatch(node)Explained result. The coordinator must also receive completions and call done before deciding the graph is exhausted. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: worker queue. Contrast the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “is_active, and boolean testing of the sorter, stays true while progress remains possible or dispatched nodes have not been marked done.” Apply this procedure: State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The coordinator must also receive completions and call done before deciding the graph is exhausted. For the worker queue, add one near-miss that exposes using an empty get_ready tuple alone as proof the workflow is finished. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: design decision. Stress-test the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “is_active, and boolean testing of the sorter, stays true while progress remains possible or dispatched nodes have not been marked done.” Apply this procedure: State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The coordinator must also receive completions and call done before deciding the graph is exhausted. For the design decision, add one near-miss that exposes using an empty get_ready tuple alone as proof the workflow is finished. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework plan. Explain the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “is_active, and boolean testing of the sorter, stays true while progress remains possible or dispatched nodes have not been marked done.” Apply this procedure: State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The coordinator must also receive completions and call done before deciding the graph is exhausted. For the homework plan, add one near-miss that exposes using an empty get_ready tuple alone as proof the workflow is finished. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science project. Transfer the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “is_active, and boolean testing of the sorter, stays true while progress remains possible or dispatched nodes have not been marked done.” Apply this procedure: State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The coordinator must also receive completions and call done before deciding the graph is exhausted. For the science project, add one near-miss that exposes using an empty get_ready tuple alone as proof the workflow is finished. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using an empty get_ready tuple alone as proof the workflow is finished.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from is_active describes unfinished schedulable work?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using an empty get_ready tuple alone as proof the workflow is finished be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework plan with revision tasks depend on earlier notes and prerequisite examples. Include one ordinary case, one boundary and one deliberate failure caused by using an empty get_ready tuple alone as proof the workflow is finished. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: is_active, and boolean testing of the sorter, stays true while progress remains possible or dispatched nodes have not been marked done. It shows a trace, not only a final value. The ordinary case should demonstrate “The coordinator must also receive completions and call done before deciding the graph is exhausted.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for is_active describes unfinished schedulable work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For is_active describes unfinished schedulable work, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 13 OF 20 . Debug and verify
13. CycleError identifies impossible prerequisite loops
prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is catching the error and silently running tasks in arbitrary order. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the CycleError identifies impossible prerequisite loops chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on catching the error and silently running tasks in arbitrary order. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
graph={'a':{'c'},'b':{'a'},'c':{'b'}}Explained result. a, b and c form a cycle, so no complete prerequisite-respecting order exists. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework plan. Stress-test the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order.” Apply this procedure: State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: a, b and c form a cycle, so no complete prerequisite-respecting order exists. For the homework plan, add one near-miss that exposes catching the error and silently running tasks in arbitrary order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science project. Explain the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order.” Apply this procedure: State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: a, b and c form a cycle, so no complete prerequisite-respecting order exists. For the science project, add one near-miss that exposes catching the error and silently running tasks in arbitrary order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA event. Transfer the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order.” Apply this procedure: State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: a, b and c form a cycle, so no complete prerequisite-respecting order exists. For the CCA event, add one near-miss that exposes catching the error and silently running tasks in arbitrary order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: coding build. Predict the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order.” Apply this procedure: State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: a, b and c form a cycle, so no complete prerequisite-respecting order exists. For the coding build, add one near-miss that exposes catching the error and silently running tasks in arbitrary order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers catching the error and silently running tasks in arbitrary order.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from CycleError identifies impossible prerequisite loops?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing catching the error and silently running tasks in arbitrary order be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science project with data collection must finish before graphs and conclusions can begin. Include one ordinary case, one boundary and one deliberate failure caused by catching the error and silently running tasks in arbitrary order. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order. It shows a trace, not only a final value. The ordinary case should demonstrate “a, b and c form a cycle, so no complete prerequisite-respecting order exists.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For CycleError identifies impossible prerequisite loops, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 14 OF 20 . Debug and verify
14. A cyclic graph may still have useful acyclic work
After CycleError from prepare, get_ready can still expose nodes that are not blocked by cycles until progress reaches the cyclic remainder. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is discarding all independent work because one component cycles. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the A cyclic graph may still have useful acyclic work chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on discarding all independent work because one component cycles. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
graph={'free':set(),'a':{'b'},'b':{'a'}}Explained result. free can still be processed even though a and b remain mutually blocked. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA event. Explain the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After CycleError from prepare, get_ready can still expose nodes that are not blocked by cycles until progress reaches the cyclic remainder.” Apply this procedure: State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: free can still be processed even though a and b remain mutually blocked. For the CCA event, add one near-miss that exposes discarding all independent work because one component cycles. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: coding build. Transfer the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After CycleError from prepare, get_ready can still expose nodes that are not blocked by cycles until progress reaches the cyclic remainder.” Apply this procedure: State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: free can still be processed even though a and b remain mutually blocked. For the coding build, add one near-miss that exposes discarding all independent work because one component cycles. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: family errand. Predict the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After CycleError from prepare, get_ready can still expose nodes that are not blocked by cycles until progress reaches the cyclic remainder.” Apply this procedure: State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: free can still be processed even though a and b remain mutually blocked. For the family errand, add one near-miss that exposes discarding all independent work because one component cycles. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: cycle laboratory. Contrast the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After CycleError from prepare, get_ready can still expose nodes that are not blocked by cycles until progress reaches the cyclic remainder.” Apply this procedure: State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: free can still be processed even though a and b remain mutually blocked. For the cycle laboratory, add one near-miss that exposes discarding all independent work because one component cycles. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers discarding all independent work because one component cycles.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from A cyclic graph may still have useful acyclic work?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing discarding all independent work because one component cycles be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA event with venue confirmation unlocks printing and logistics tasks. Include one ordinary case, one boundary and one deliberate failure caused by discarding all independent work because one component cycles. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: After CycleError from prepare, get_ready can still expose nodes that are not blocked by cycles until progress reaches the cyclic remainder. It shows a trace, not only a final value. The ordinary case should demonstrate “free can still be processed even though a and b remain mutually blocked.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for A cyclic graph may still have useful acyclic work, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A cyclic graph may still have useful acyclic work, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 15 OF 20 . Debug and verify
15. Cycle diagnostics should expose a concrete loop
The CycleError arguments include information that helps reveal at least one cycle rather than merely saying sorting failed. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is showing a generic failure without the task names involved. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Cycle diagnostics should expose a concrete loop chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on showing a generic failure without the task names involved. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
try: TopologicalSorter(graph).prepare()
except CycleError as exc: print(exc.args)Explained result. The diagnostic can guide removal or correction of a specific circular prerequisite. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: family errand. Transfer the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The CycleError arguments include information that helps reveal at least one cycle rather than merely saying sorting failed.” Apply this procedure: State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The diagnostic can guide removal or correction of a specific circular prerequisite. For the family errand, add one near-miss that exposes showing a generic failure without the task names involved. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: cycle laboratory. Predict the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The CycleError arguments include information that helps reveal at least one cycle rather than merely saying sorting failed.” Apply this procedure: State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The diagnostic can guide removal or correction of a specific circular prerequisite. For the cycle laboratory, add one near-miss that exposes showing a generic failure without the task names involved. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: worker queue. Contrast the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The CycleError arguments include information that helps reveal at least one cycle rather than merely saying sorting failed.” Apply this procedure: State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The diagnostic can guide removal or correction of a specific circular prerequisite. For the worker queue, add one near-miss that exposes showing a generic failure without the task names involved. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: design decision. Stress-test the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The CycleError arguments include information that helps reveal at least one cycle rather than merely saying sorting failed.” Apply this procedure: State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The diagnostic can guide removal or correction of a specific circular prerequisite. For the design decision, add one near-miss that exposes showing a generic failure without the task names involved. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers showing a generic failure without the task names involved.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Cycle diagnostics should expose a concrete loop?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing showing a generic failure without the task names involved be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny coding build with generated files depend on source and configuration steps. Include one ordinary case, one boundary and one deliberate failure caused by showing a generic failure without the task names involved. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The CycleError arguments include information that helps reveal at least one cycle rather than merely saying sorting failed. It shows a trace, not only a final value. The ordinary case should demonstrate “The diagnostic can guide removal or correction of a specific circular prerequisite.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Cycle diagnostics should expose a concrete loop, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Cycle diagnostics should expose a concrete loop, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is building queues and done signals for a single-threaded script. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the static_order is the simple sequential route chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on building queues and done signals for a single-threaded script. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
order=tuple(TopologicalSorter(graph).static_order())Explained result. order is one valid sequence; another valid graph order may also exist. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: worker queue. Predict the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption.” Apply this procedure: State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: order is one valid sequence; another valid graph order may also exist. For the worker queue, add one near-miss that exposes building queues and done signals for a single-threaded script. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: design decision. Contrast the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption.” Apply this procedure: State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: order is one valid sequence; another valid graph order may also exist. For the design decision, add one near-miss that exposes building queues and done signals for a single-threaded script. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework plan. Stress-test the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption.” Apply this procedure: State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: order is one valid sequence; another valid graph order may also exist. For the homework plan, add one near-miss that exposes building queues and done signals for a single-threaded script. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science project. Explain the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption.” Apply this procedure: State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: order is one valid sequence; another valid graph order may also exist. For the science project, add one near-miss that exposes building queues and done signals for a single-threaded script. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers building queues and done signals for a single-threaded script.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from static_order is the simple sequential route?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing building queues and done signals for a single-threaded script be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family errand with several independent stops become ready after one shared preparation. Include one ordinary case, one boundary and one deliberate failure caused by building queues and done signals for a single-threaded script. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption. It shows a trace, not only a final value. The ordinary case should demonstrate “order is one valid sequence; another valid graph order may also exist.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For static_order is the simple sequential route, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 17 OF 20 . Transfer with judgment
17. A graph can have more than one valid order
When independent nodes exist, topological sorting does not define one universal sequence unless another project policy adds a tie-break. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is writing tests that require an unnecessary exact order. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the A graph can have more than one valid order chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing tests that require an unnecessary exact order. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
graph={'a':set(),'b':set(),'c':{'a','b'}}Explained result. Either a or b may appear first, but both must precede c. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework plan. Contrast the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “When independent nodes exist, topological sorting does not define one universal sequence unless another project policy adds a tie-break.” Apply this procedure: State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Either a or b may appear first, but both must precede c. For the homework plan, add one near-miss that exposes writing tests that require an unnecessary exact order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science project. Stress-test the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “When independent nodes exist, topological sorting does not define one universal sequence unless another project policy adds a tie-break.” Apply this procedure: State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Either a or b may appear first, but both must precede c. For the science project, add one near-miss that exposes writing tests that require an unnecessary exact order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA event. Explain the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “When independent nodes exist, topological sorting does not define one universal sequence unless another project policy adds a tie-break.” Apply this procedure: State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Either a or b may appear first, but both must precede c. For the CCA event, add one near-miss that exposes writing tests that require an unnecessary exact order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: coding build. Transfer the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “When independent nodes exist, topological sorting does not define one universal sequence unless another project policy adds a tie-break.” Apply this procedure: State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: Either a or b may appear first, but both must precede c. For the coding build, add one near-miss that exposes writing tests that require an unnecessary exact order. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers writing tests that require an unnecessary exact order.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from A graph can have more than one valid order?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing tests that require an unnecessary exact order be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny cycle laboratory with three tasks accidentally depend on one another and block progress. Include one ordinary case, one boundary and one deliberate failure caused by writing tests that require an unnecessary exact order. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: When independent nodes exist, topological sorting does not define one universal sequence unless another project policy adds a tie-break. It shows a trace, not only a final value. The ordinary case should demonstrate “Either a or b may appear first, but both must precede c.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for A graph can have more than one valid order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A graph can have more than one valid order, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
In a worker design, one coordinator can call get_ready and done while workers report outcomes through queues, keeping state transitions auditable. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is letting workers mutate scheduler state without a protocol. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the A coordinator should own sorter state chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on letting workers mutate scheduler state without a protocol. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
# coordinator: ready -> work queue; result queue -> doneExplained result. The sorter remains the prerequisite authority while workers execute task-specific code. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA event. Stress-test the rule using venue confirmation unlocks printing and logistics tasks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “In a worker design, one coordinator can call get_ready and done while workers report outcomes through queues, keeping state transitions auditable.” Apply this procedure: State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter remains the prerequisite authority while workers execute task-specific code. For the CCA event, add one near-miss that exposes letting workers mutate scheduler state without a protocol. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: coding build. Explain the rule using generated files depend on source and configuration steps. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “In a worker design, one coordinator can call get_ready and done while workers report outcomes through queues, keeping state transitions auditable.” Apply this procedure: State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter remains the prerequisite authority while workers execute task-specific code. For the coding build, add one near-miss that exposes letting workers mutate scheduler state without a protocol. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: family errand. Transfer the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “In a worker design, one coordinator can call get_ready and done while workers report outcomes through queues, keeping state transitions auditable.” Apply this procedure: State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter remains the prerequisite authority while workers execute task-specific code. For the family errand, add one near-miss that exposes letting workers mutate scheduler state without a protocol. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: cycle laboratory. Predict the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “In a worker design, one coordinator can call get_ready and done while workers report outcomes through queues, keeping state transitions auditable.” Apply this procedure: State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The sorter remains the prerequisite authority while workers execute task-specific code. For the cycle laboratory, add one near-miss that exposes letting workers mutate scheduler state without a protocol. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers letting workers mutate scheduler state without a protocol.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from A coordinator should own sorter state?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing letting workers mutate scheduler state without a protocol be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny worker queue with a coordinator dispatches ready jobs and records completion centrally. Include one ordinary case, one boundary and one deliberate failure caused by letting workers mutate scheduler state without a protocol. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: In a worker design, one coordinator can call get_ready and done while workers report outcomes through queues, keeping state transitions auditable. It shows a trace, not only a final value. The ordinary case should demonstrate “The sorter remains the prerequisite authority while workers execute task-specific code.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for A coordinator should own sorter state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A coordinator should own sorter state, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 19 OF 20 . Transfer with judgment
19. Failures need an explicit downstream policy
TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling done after failure without defining what completion means. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Failures need an explicit downstream policy chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling done after failure without defining what completion means. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
# Policy: only successful jobs call done; failed jobs enter retry reviewExplained result. The application, not graphlib, defines failure and recovery semantics. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: family errand. Explain the rule using several independent stops become ready after one shared preparation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow.” Apply this procedure: State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The application, not graphlib, defines failure and recovery semantics. For the family errand, add one near-miss that exposes calling done after failure without defining what completion means. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: cycle laboratory. Transfer the rule using three tasks accidentally depend on one another and block progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow.” Apply this procedure: State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The application, not graphlib, defines failure and recovery semantics. For the cycle laboratory, add one near-miss that exposes calling done after failure without defining what completion means. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: worker queue. Predict the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow.” Apply this procedure: State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The application, not graphlib, defines failure and recovery semantics. For the worker queue, add one near-miss that exposes calling done after failure without defining what completion means. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: design decision. Contrast the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow.” Apply this procedure: State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The application, not graphlib, defines failure and recovery semantics. For the design decision, add one near-miss that exposes calling done after failure without defining what completion means. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling done after failure without defining what completion means.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Failures need an explicit downstream policy?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling done after failure without defining what completion means be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny design decision with a fixed sequential order is compared with dynamic multi-worker scheduling. Include one ordinary case, one boundary and one deliberate failure caused by calling done after failure without defining what completion means. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow. It shows a trace, not only a final value. The ordinary case should demonstrate “The application, not graphlib, defines failure and recovery semantics.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Failures need an explicit downstream policy, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 20 OF 20 . Transfer with judgment
20. Choose graph scheduling only for real dependencies
TopologicalSorter helps when prerequisites form a directed acyclic graph; a plain list is clearer when the order is already fixed and never branches. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is turning every checklist into a graph. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.
For the Choose graph scheduling only for real dependencies chapter on Python graphlib.TopologicalSorter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on turning every checklist into a graph. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
# Fixed routine: use a list; branching prerequisites: use TopologicalSorterExplained result. The abstraction is selected because dependencies matter, not because a graph sounds advanced. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: worker queue. Transfer the rule using a coordinator dispatches ready jobs and records completion centrally. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter helps when prerequisites form a directed acyclic graph; a plain list is clearer when the order is already fixed and never branches.” Apply this procedure: State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The abstraction is selected because dependencies matter, not because a graph sounds advanced. For the worker queue, add one near-miss that exposes turning every checklist into a graph. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: design decision. Predict the rule using a fixed sequential order is compared with dynamic multi-worker scheduling. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter helps when prerequisites form a directed acyclic graph; a plain list is clearer when the order is already fixed and never branches.” Apply this procedure: State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The abstraction is selected because dependencies matter, not because a graph sounds advanced. For the design decision, add one near-miss that exposes turning every checklist into a graph. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework plan. Contrast the rule using revision tasks depend on earlier notes and prerequisite examples. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter helps when prerequisites form a directed acyclic graph; a plain list is clearer when the order is already fixed and never branches.” Apply this procedure: State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The abstraction is selected because dependencies matter, not because a graph sounds advanced. For the homework plan, add one near-miss that exposes turning every checklist into a graph. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science project. Stress-test the rule using data collection must finish before graphs and conclusions can begin. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “TopologicalSorter helps when prerequisites form a directed acyclic graph; a plain list is clearer when the order is already fixed and never branches.” Apply this procedure: State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. The expected mechanism is: The abstraction is selected because dependencies matter, not because a graph sounds advanced. For the science project, add one near-miss that exposes turning every checklist into a graph. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers turning every checklist into a graph.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Python graphlib.TopologicalSorter syntax. For this chapter, useful prompts are: “What did you expect from Choose graph scheduling only for real dependencies?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing turning every checklist into a graph be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework plan with revision tasks depend on earlier notes and prerequisite examples. Include one ordinary case, one boundary and one deliberate failure caused by turning every checklist into a graph. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: TopologicalSorter helps when prerequisites form a directed acyclic graph; a plain list is clearer when the order is already fixed and never branches. It shows a trace, not only a final value. The ordinary case should demonstrate “The abstraction is selected because dependencies matter, not because a graph sounds advanced.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: State the contract for Choose graph scheduling only for real dependencies, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Choose graph scheduling only for real dependencies, separate the documented Python graphlib.TopologicalSorter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. homework plan: model, boundary and recovery
Create a small homework plan using revision tasks depend on earlier notes and prerequisite examples. Combine “A topological order respects prerequisites” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A topological order places every predecessor before each node that depends on it. Apply: State the contract for A topological order respects prerequisites, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: The only valid sequence is draft, review, submit. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. science project: model, boundary and recovery
Create a small science project using data collection must finish before graphs and conclusions can begin. Combine “Construct from a mapping or add incrementally” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A sorter can receive the whole predecessor mapping or accumulate nodes and dependencies with add before preparation. Apply: State the contract for Construct from a mapping or add incrementally, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: The incremental graph records draft as the predecessor of review. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
3. CCA event: model, boundary and recovery
Create a small CCA event using venue confirmation unlocks printing and logistics tasks. Combine “prepare freezes the graph for scheduling” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: prepare validates the graph and establishes internal readiness state before get_ready and done are used. Apply: State the contract for prepare freezes the graph for scheduling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: The sorter is ready to report initial nodes and should no longer receive add calls. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
4. coding build: model, boundary and recovery
Create a small coding build using generated files depend on source and configuration steps. Combine “Several nodes can be ready together” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Independent nodes or nodes whose prerequisites are all complete may appear in the same ready batch. Apply: State the contract for Several nodes can be ready together, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: write and draw can be ready together; assemble waits for both. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. family errand: model, boundary and recovery
Create a small family errand using several independent stops become ready after one shared preparation. Combine “CycleError identifies impossible prerequisite loops” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: prepare or static ordering raises CycleError when a directed cycle prevents a complete topological order. Apply: State the contract for CycleError identifies impossible prerequisite loops, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: a, b and c form a cycle, so no complete prerequisite-respecting order exists. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. cycle laboratory: model, boundary and recovery
Create a small cycle laboratory using three tasks accidentally depend on one another and block progress. Combine “static_order is the simple sequential route” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: static_order returns an iterator over one valid topological order and handles preparation internally for ordinary sequential consumption. Apply: State the contract for static_order is the simple sequential route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: order is one valid sequence; another valid graph order may also exist. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
7. worker queue: model, boundary and recovery
Create a small worker queue using a coordinator dispatches ready jobs and records completion centrally. Combine “Failures need an explicit downstream policy” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: TopologicalSorter records completion ordering, not whether a failed task should unlock dependants, retry or cancel the workflow. Apply: State the contract for Failures need an explicit downstream policy, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: The application, not graphlib, defines failure and recovery semantics. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. design decision: model, boundary and recovery
Create a small design decision using a fixed sequential order is compared with dynamic multi-worker scheduling. Combine “The mapping points from node to predecessors” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: TopologicalSorter expects each mapping value to contain prerequisites of the key, not the tasks that follow it. Apply: State the contract for The mapping points from node to predecessors, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence. Verify: source must be ready before build, and build before test. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
Frequently asked questions
How long should a practice session be?
Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.
Should every option or function be memorised?
No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.
What if the result is correct but the explanation is weak?
Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.
Is the shortest solution the best?
Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.
When should official documentation be used?
Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.
How can a parent help without technical expertise?
Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.
How do we test transfer?
Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.
What should be saved after practice?
Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.
Can these exercises replace backups?
No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.
What counts as mastery?
The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.
