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 structural pattern matching uses a match subject and ordered case patterns to test shape, constants, types and nested structure while optionally binding names. Mastery means predicting which case is attempted first, which names are captured, why a near-match fails and when an ordinary conditional is clearer. 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.

A match statement evaluates its subject once, then tries case blocks from top to bottom until the first pattern and guard succeed. 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 reading match as a switch on one scalar value. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write the subject value, list the cases in order and annotate the first structural test each case performs.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match event:
    case ('done', task):
        result = task
    case _:
        result = None

Four purposeful transfer cases

Case 1: homework message. Predict the rule using a command name, subject code and optional due date. 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.

Case 2: library record. Contrast the rule using a mapping with title, format and borrowing state. 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.

Case 3: CCA attendance. Stress-test the rule using tagged tuples for present, absent and late records. 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.

Case 4: science reading. Explain the rule using a class with quantity, unit and validity flag. 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.

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 reading match as a switch on one scalar value.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Write the subject value, list the cases in order and annotate the first structural test each case performs.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny revision card with a status tag and a list of evidence items. Include one ordinary case, one boundary and one deliberate failure caused by reading match as a switch on one scalar value. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Literal patterns compare the subject with a stated literal, using equality semantics except for the singleton checks involving None, True and False. 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 a bare name when a fixed constant was intended. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a quoted literal, a singleton or a qualified value for a fixed target; test a near-miss of the same type.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match status:
    case 'ready':
        start()
    case None:
        wait()

Four purposeful transfer cases

Case 1: CCA attendance. Contrast the rule using tagged tuples for present, absent and late records. 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.

Case 2: science reading. Stress-test the rule using a class with quantity, unit and validity flag. 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.

Case 3: transport update. Explain the rule using nested mappings for line, stop and delay. 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.

Case 4: revision card. Transfer the rule using a status tag and a list of evidence items. 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.

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 a bare name when a fixed constant was intended.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use a quoted literal, a singleton or a qualified value for a fixed target; test a near-miss of the same type.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny quiz response with multiple answer shapes and a confidence value. Include one ordinary case, one boundary and one deliberate failure caused by writing a bare name when a fixed constant was intended. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A bare unqualified name in a pattern captures the corresponding value and normally matches anything at that position. 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 case RED to compare with an ordinary variable named RED. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a literal, Enum member or other qualified value for comparison; reserve bare names for deliberate capture.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match point:
    case (0, y):
        label = f'y={y}'

Four purposeful transfer cases

Case 1: transport update. Stress-test the rule using nested mappings for line, stop and delay. 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.

Case 2: revision card. Explain the rule using a status tag and a list of evidence items. 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.

Case 3: quiz response. Transfer the rule using multiple answer shapes and a confidence value. 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.

Case 4: file event. Predict the rule using a path action with optional metadata. 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.

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 case RED to compare with an ordinary variable named RED.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use a literal, Enum member or other qualified value for comparison; reserve bare names for deliberate capture.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny file event with a path action with optional metadata. Include one ordinary case, one boundary and one deliberate failure caused by expecting case RED to compare with an ordinary variable named RED. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

The underscore wildcard matches without binding a usable name, making it suitable for ignored positions and explicit fallbacks. 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 a named capture as a fallback and then mistaking it for a constant. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose underscore when the value has no later role and place a broad fallback last.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match record:
    case ('ok', value, _):
        keep(value)

Four purposeful transfer cases

Case 1: quiz response. Explain the rule using multiple answer shapes and a confidence value. 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.

Case 2: file event. Transfer the rule using a path action with optional metadata. 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.

Case 3: homework message. Predict the rule using a command name, subject code and optional due date. 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.

Case 4: library record. Contrast the rule using a mapping with title, format and borrowing state. 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.

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 a named capture as a fallback and then mistaking it for a constant.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Choose underscore when the value has no later role and place a broad fallback last.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny homework message with a command name, subject code and optional due date. Include one ordinary case, one boundary and one deliberate failure caused by using a named capture as a fallback and then mistaking it for a constant. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A sequence pattern matches supported sequence structure and element patterns, but strings and bytes are not treated as general sequence-pattern subjects. 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 every iterable, including a generator or string, matches a sequence pattern. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test the documented sequence category and verify exact length before adding a star pattern.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match command:
    case ['move', x, y]:
        move(int(x), int(y))

Four purposeful transfer cases

Case 1: homework message. Transfer the rule using a command name, subject code and optional due date. 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.

Case 2: library record. Predict the rule using a mapping with title, format and borrowing state. 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.

Case 3: CCA attendance. Contrast the rule using tagged tuples for present, absent and late records. 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.

Case 4: science reading. Stress-test the rule using a class with quantity, unit and validity flag. 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.

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 every iterable, including a generator or string, matches a sequence pattern.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test the documented sequence category and verify exact length before adding a star pattern.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny library record with a mapping with title, format and borrowing state. Include one ordinary case, one boundary and one deliberate failure caused by assuming every iterable, including a generator or string, matches a sequence pattern. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

One starred subpattern can collect zero or more middle, leading or trailing items while the remaining positions still have fixed obligations. 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 the star requires at least one captured item. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test the empty collection, one item and several items, then inspect the captured list.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match route:
    case [start, *stops, end]:
        plan(start, stops, end)

Four purposeful transfer cases

Case 1: CCA attendance. Predict the rule using tagged tuples for present, absent and late records. 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.

Case 2: science reading. Contrast the rule using a class with quantity, unit and validity flag. 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.

Case 3: transport update. Stress-test the rule using nested mappings for line, stop and delay. 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.

Case 4: revision card. Explain the rule using a status tag and a list of evidence items. 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.

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 the star requires at least one captured item.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test the empty collection, one item and several items, then inspect the captured list.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny CCA attendance with tagged tuples for present, absent and late records. Include one ordinary case, one boundary and one deliberate failure caused by assuming the star requires at least one captured item. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A mapping pattern asks for specified keys and applies subpatterns to their values; extra keys are normally allowed. 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 a mapping pattern like exact dictionary equality. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. List required keys separately from permitted extras and use a rest capture only when extras matter.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match payload:
    case {'type':'quiz','score':score}:
        record(score)

Four purposeful transfer cases

Case 1: transport update. Contrast the rule using nested mappings for line, stop and delay. 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.

Case 2: revision card. Stress-test the rule using a status tag and a list of evidence items. 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.

Case 3: quiz response. Explain the rule using multiple answer shapes and a confidence value. 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.

Case 4: file event. Transfer the rule using a path action with optional metadata. 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.

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 a mapping pattern like exact dictionary equality.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “List required keys separately from permitted extras and use a rest capture only when extras matter.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny science reading with a class with quantity, unit and validity flag. Include one ordinary case, one boundary and one deliberate failure caused by treating a mapping pattern like exact dictionary equality. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A double-star capture in a mapping pattern collects unmatched key-value pairs after required keys are satisfied. 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 missing required keys to appear in the rest mapping. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Validate required keys first, then inspect or reject extras according to project policy.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match data:
    case {'id': ident, **extra}:
        save(ident, extra)

Four purposeful transfer cases

Case 1: quiz response. Stress-test the rule using multiple answer shapes and a confidence value. 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.

Case 2: file event. Explain the rule using a path action with optional metadata. 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.

Case 3: homework message. Transfer the rule using a command name, subject code and optional due date. 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.

Case 4: library record. Predict the rule using a mapping with title, format and borrowing state. 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.

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 missing required keys to appear in the rest mapping.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Validate required keys first, then inspect or reject extras according to project policy.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny transport update with nested mappings for line, stop and delay. Include one ordinary case, one boundary and one deliberate failure caused by expecting missing required keys to appear in the rest mapping. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A class pattern first checks the subject type and then matches named attributes or supported positional fields. 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 believing the syntax calls the class constructor. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Treat the class name as a type pattern and verify the attributes exposed to matching.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match reading:
    case Reading(value=v, unit='cm'):
        use(v)

Four purposeful transfer cases

Case 1: homework message. Explain the rule using a command name, subject code and optional due date. 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.

Case 2: library record. Transfer the rule using a mapping with title, format and borrowing state. 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.

Case 3: CCA attendance. Predict the rule using tagged tuples for present, absent and late records. 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.

Case 4: science reading. Contrast the rule using a class with quantity, unit and validity flag. 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.

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 believing the syntax calls the class constructor.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Treat the class name as a type pattern and verify the attributes exposed to matching.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny revision card with a status tag and a list of evidence items. Include one ordinary case, one boundary and one deliberate failure caused by believing the syntax calls the class constructor. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Positional class patterns are translated using the class __match_args__ contract, so position is an API decision rather than a visual guess. 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 constructor parameter order always defines positional matching. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect __match_args__ and prefer keyword patterns when field meaning should remain explicit.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

class Point:
    __match_args__ = ('x','y')
match p:
    case Point(0, y): ...

Four purposeful transfer cases

Case 1: CCA attendance. Transfer the rule using tagged tuples for present, absent and late records. 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.

Case 2: science reading. Predict the rule using a class with quantity, unit and validity flag. 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.

Case 3: transport update. Contrast the rule using nested mappings for line, stop and delay. 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.

Case 4: revision card. Stress-test the rule using a status tag and a list of evidence items. 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.

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 constructor parameter order always defines positional matching.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect __match_args__ and prefer keyword patterns when field meaning should remain explicit.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny quiz response with multiple answer shapes and a confidence value. Include one ordinary case, one boundary and one deliberate failure caused by assuming constructor parameter order always defines positional matching. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

An OR pattern succeeds when any alternative succeeds, and every alternative must bind the same set of names. 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 binding a name in only one alternative and expecting it to exist conditionally. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Align bindings across alternatives and test each branch plus a near-miss.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match command:
    case ('quit', code) | ('exit', code):
        stop(code)

Four purposeful transfer cases

Case 1: transport update. Predict the rule using nested mappings for line, stop and delay. 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.

Case 2: revision card. Contrast the rule using a status tag and a list of evidence items. 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.

Case 3: quiz response. Stress-test the rule using multiple answer shapes and a confidence value. 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.

Case 4: file event. Explain the rule using a path action with optional metadata. 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.

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 binding a name in only one alternative and expecting it to exist conditionally.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Align bindings across alternatives and test each branch plus a near-miss.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny file event with a path action with optional metadata. Include one ordinary case, one boundary and one deliberate failure caused by binding a name in only one alternative and expecting it to exist conditionally. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

An AS pattern matches a subpattern and also binds the entire matched value, preserving both parts and context. 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 reconstructing the whole value from captures when identity or extra fields matter. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a narrow subpattern followed by as name, then state why the whole subject is needed.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match point:
    case (x, y) as pair:
        log(pair, x, y)

Four purposeful transfer cases

Case 1: quiz response. Contrast the rule using multiple answer shapes and a confidence value. 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.

Case 2: file event. Stress-test the rule using a path action with optional metadata. 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.

Case 3: homework message. Explain the rule using a command name, subject code and optional due date. 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.

Case 4: library record. Transfer the rule using a mapping with title, format and borrowing state. 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.

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 reconstructing the whole value from captures when identity or extra fields matter.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use a narrow subpattern followed by as name, then state why the whole subject is needed.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny homework message with a command name, subject code and optional due date. Include one ordinary case, one boundary and one deliberate failure caused by reconstructing the whole value from captures when identity or extra fields matter. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A guard runs only after its pattern succeeds and its captures are available; a false guard continues with later cases. 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 putting side effects in a guard and forgetting that failed guards still evaluated them. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep guards short and pure, and separate structural eligibility from an additional boolean policy.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match result:
    case {'score': s} if s >= 75:
        band = 'strong'
    case {'score': s}:
        band = 'developing'

Four purposeful transfer cases

Case 1: homework message. Stress-test the rule using a command name, subject code and optional due date. 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.

Case 2: library record. Explain the rule using a mapping with title, format and borrowing state. 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.

Case 3: CCA attendance. Transfer the rule using tagged tuples for present, absent and late records. 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.

Case 4: science reading. Predict the rule using a class with quantity, unit and validity flag. 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.

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 putting side effects in a guard and forgetting that failed guards still evaluated them.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep guards short and pure, and separate structural eligibility from an additional boolean policy.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny library record with a mapping with title, format and borrowing state. Include one ordinary case, one boundary and one deliberate failure caused by putting side effects in a guard and forgetting that failed guards still evaluated them. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Because only the first successful case runs, specific patterns must normally precede patterns that subsume them. 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 placing a capture or wildcard before narrower cases. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. For every adjacent pair, ask whether an earlier case can already accept every subject of the later one.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match value:
    case 0: label='zero'
    case int(): label='integer'
    case _: label='other'

Four purposeful transfer cases

Case 1: CCA attendance. Explain the rule using tagged tuples for present, absent and late records. 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.

Case 2: science reading. Transfer the rule using a class with quantity, unit and validity flag. 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.

Case 3: transport update. Predict the rule using nested mappings for line, stop and delay. 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.

Case 4: revision card. Contrast the rule using a status tag and a list of evidence items. 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.

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 placing a capture or wildcard before narrower cases.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “For every adjacent pair, ask whether an earlier case can already accept every subject of the later one.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny CCA attendance with tagged tuples for present, absent and late records. Include one ordinary case, one boundary and one deliberate failure caused by placing a capture or wildcard before narrower cases. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Bindings made while attempting a pattern that later fails should not be used as a portable program contract; code should rely only on names from the selected case. 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 reading partially bound local names after the match statement. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep work inside the case body or assign one explicit result in every successful branch.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match subject:
    case [x, 0]:
        result = x
    case _:
        result = None

Four purposeful transfer cases

Case 1: transport update. Transfer the rule using nested mappings for line, stop and delay. 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.

Case 2: revision card. Predict the rule using a status tag and a list of evidence items. 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.

Case 3: quiz response. Contrast the rule using multiple answer shapes and a confidence value. 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.

Case 4: file event. Stress-test the rule using a path action with optional metadata. 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.

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 reading partially bound local names after the match statement.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep work inside the case body or assign one explicit result in every successful branch.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny science reading with a class with quantity, unit and validity flag. Include one ordinary case, one boundary and one deliberate failure caused by reading partially bound local names after the match statement. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Several built-in classes accept a single positional subpattern that matches the whole value, enabling concise type-and-value tests. 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 all user classes inherit the same single-positional behaviour. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check the documented special cases and prefer explicit named attributes for user-defined classes.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match value:
    case int(n) if n > 0:
        label='positive int'

Four purposeful transfer cases

Case 1: quiz response. Predict the rule using multiple answer shapes and a confidence value. 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.

Case 2: file event. Contrast the rule using a path action with optional metadata. 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.

Case 3: homework message. Stress-test the rule using a command name, subject code and optional due date. 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.

Case 4: library record. Explain the rule using a mapping with title, format and borrowing state. 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.

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 all user classes inherit the same single-positional behaviour.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Check the documented special cases and prefer explicit named attributes for user-defined classes.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny transport update with nested mappings for line, stop and delay. Include one ordinary case, one boundary and one deliberate failure caused by assuming all user classes inherit the same single-positional behaviour. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Patterns compose recursively, so nested sequences, mappings and class patterns can express a data schema directly. 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 a deeply nested pattern that hides the first failing boundary. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Indent the expected shape as a tree and split validation into stages when the pattern becomes difficult to explain.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

match event:
    case {'type':'reading','data':{'value':v,'unit':u}}:
        use(v,u)

Four purposeful transfer cases

Case 1: homework message. Contrast the rule using a command name, subject code and optional due date. 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.

Case 2: library record. Stress-test the rule using a mapping with title, format and borrowing state. 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.

Case 3: CCA attendance. Explain the rule using tagged tuples for present, absent and late records. 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.

Case 4: science reading. Transfer the rule using a class with quantity, unit and validity flag. 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.

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 a deeply nested pattern that hides the first failing boundary.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Indent the expected shape as a tree and split validation into stages when the pattern becomes difficult to explain.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny revision card with a status tag and a list of evidence items. Include one ordinary case, one boundary and one deliberate failure caused by writing a deeply nested pattern that hides the first failing boundary. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

A successful pattern establishes only the stated structural and guard conditions; it does not automatically validate every domain rule or reject extra mapping data. 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 one matched case as proof the whole input is trustworthy. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. List unstated invariants and validate them explicitly at the appropriate boundary.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

case {'age': int(age)} if 0 <= age <= 120: ...

Four purposeful transfer cases

Case 1: CCA attendance. Stress-test the rule using tagged tuples for present, absent and late records. 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.

Case 2: science reading. Explain the rule using a class with quantity, unit and validity flag. 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.

Case 3: transport update. Transfer the rule using nested mappings for line, stop and delay. 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.

Case 4: revision card. Predict the rule using a status tag and a list of evidence items. 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.

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 one matched case as proof the whole input is trustworthy.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “List unstated invariants and validate them explicitly at the appropriate boundary.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny quiz response with multiple answer shapes and a confidence value. Include one ordinary case, one boundary and one deliberate failure caused by treating one matched case as proof the whole input is trustworthy. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Pattern matching is strongest when branching depends on decomposing several related shapes; simple predicates or key-to-function dispatch may be clearer elsewhere. 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 match merely because it is newer syntax. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare the number of shapes, nesting depth, shared actions and extension policy before choosing control flow.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

handler = handlers.get(command)
if handler:
    handler(payload)

Four purposeful transfer cases

Case 1: transport update. Explain the rule using nested mappings for line, stop and delay. 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.

Case 2: revision card. Transfer the rule using a status tag and a list of evidence items. 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.

Case 3: quiz response. Predict the rule using multiple answer shapes and a confidence value. 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.

Case 4: file event. Contrast the rule using a path action with optional metadata. 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.

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 match merely because it is newer syntax.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Compare the number of shapes, nesting depth, shared actions and extension policy before choosing control flow.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny file event with a path action with optional metadata. Include one ordinary case, one boundary and one deliberate failure caused by using match merely because it is newer syntax. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

Reliable matching comes from a subject inventory, ordered pattern table, controlled near-misses and tests for captures, guards and fallback behaviour. 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 debugging only inside the selected body while ignoring why earlier patterns failed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Reduce the subject, test one case at a time, log types and shapes, then restore order and add regression examples.

Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.

Core worked example

def classify(x):
    match x:
        case {'kind':'note','text':str(t)} if t.strip(): return 'note'
        case _: return 'other'

Four purposeful transfer cases

Case 1: quiz response. Transfer the rule using multiple answer shapes and a confidence value. 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.

Case 2: file event. Predict the rule using a path action with optional metadata. 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.

Case 3: homework message. Contrast the rule using a command name, subject code and optional due date. 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.

Case 4: library record. Stress-test the rule using a mapping with title, format and borrowing state. 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.

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 debugging only inside the selected body while ignoring why earlier patterns failed.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Reduce the subject, test one case at a time, log types and shapes, then restore order and add regression examples.” 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 syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.

Practice with an explained answer

Question. Build a tiny homework message with a command name, subject code and optional due date. Include one ordinary case, one boundary and one deliberate failure caused by debugging only inside the selected body while ignoring why earlier patterns failed. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.

Previous chapter . Contents . Next chapter

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.

1. homework message: model, boundary and recovery

Create a small homework message using a command name, subject code and optional due date. Combine “The subject-and-cases mental model” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. library record: model, boundary and recovery

Create a small library record using a mapping with title, format and borrowing state. Combine “Wildcard patterns” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. CCA attendance: model, boundary and recovery

Create a small CCA attendance using tagged tuples for present, absent and late records. Combine “Mapping patterns” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. science reading: model, boundary and recovery

Create a small science reading using a class with quantity, unit and validity flag. Combine “Positional class patterns and __match_args__” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. transport update: model, boundary and recovery

Create a small transport update using nested mappings for line, stop and delay. Combine “Guards refine successful patterns” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. revision card: model, boundary and recovery

Create a small revision card using a status tag and a list of evidence items. Combine “Built-in class patterns” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. quiz response: model, boundary and recovery

Create a small quiz response using multiple answer shapes and a confidence value. Combine “Choosing match versus if and dispatch tables” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. file event: model, boundary and recovery

Create a small file event using a path action with optional metadata. Combine “Literal patterns” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

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.

Official and supporting references

• Primary technical documentation for Python structural pattern matching
• eduKatePunggol: How Studying Works

Return to contents