PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

If a learner can recognise a .py filename but cannot tell whether a complete relative path fits a rule, the missing idea is anchoring. PurePath.full_match() is a lexical whole-path matcher, not a filesystem search and not the suffix-oriented behaviour of PurePath.match().

The central lesson is immediate: on Python 3.13 and later, full_match() compares the entire PurePath with a glob-style pattern. A single star stays inside a segment, double-star handles recursive depth, path flavour supplies the default case policy, and case_sensitive can override it explicitly.

This guide treats Python pathlib.PurePath.full_match as a reasoning skill. It begins with the governing model, moves through worked examples and diagnostic routes, and ends with transfer cases, practice with explained answers, parent decisions and FAQs. The examples are proposed home or lesson activities; they are not claims about a physical Punggol branch, school affiliation, timetable, class size, fee or guaranteed result.

For a Punggol family, the practical aim is simple: a learner should be able to use a short study block before schoolwork, after CCA, or during a weekend library session without needing a large project. Each chapter is designed so the smallest useful example can be completed, discussed and saved as a test fixture.

The official technical reference for this article is Python pathlib documentation for PurePath.full_match(). Where the feature is version-sensitive or still developing, the article states that boundary explicitly. Examples were independently checked against the runtime or specification named in the reference section.

Choose a reading route

If the immediate concern is “I can copy the syntax but I cannot explain the result”, use the first route. If a real project is already failing, use the diagnostic route. Parents can use the final route to decide whether more practice, a smaller prerequisite or a different example is needed. For the wider learning framework, see How Studying Works.

Start from the model: Chapters 1–4. Begin with The whole-path question and continue in order to Absolute paths need anchored thinking.

Diagnose a confusing result: Chapters 5–8. Begin with Single-star segment boundaries and continue in order to Character classes.

Build reliable examples: Chapters 9–12. Begin with Literal punctuation and extensions and continue in order to Explicit case-sensitive override.

Transfer to real work: Chapters 13–16. Begin with Explicit case-insensitive override and continue in order to Recursive semantics versus match().

Decide and teach: Chapters 17–20. Begin with Allow-lists before deny-lists and continue in order to Choosing full_match() for the right job.

Open the full 20-chapter index

1. 1. The whole-path question
2. 2. A lexical operation, not a disk query
3. 3. Relative paths and relative patterns
4. 4. Absolute paths need anchored thinking
5. 5. Single-star segment boundaries
6. 6. Recursive double-star
7. 7. Question-mark width
8. 8. Character classes
9. 9. Literal punctuation and extensions
10. 10. POSIX default case sensitivity
11. 11. Windows default case insensitivity
12. 12. Explicit case-sensitive override
13. 13. Explicit case-insensitive override
14. 14. PurePath and concrete Path
15. 15. full_match() versus match()
16. 16. Recursive semantics versus match()
17. 17. Allow-lists before deny-lists
18. 18. Version gate at Python 3.13
19. 19. Table-driven pattern tests
20. 20. Choosing full_match() for the right job

CHAPTER 1 OF 20 · Back to contents

1. The whole-path question

The short answer: full_match() asks whether the entire PurePath matches a glob-style pattern. The governing rule is: The pattern must account for the full path rather than merely a suffix.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Python tokenises the path and pattern by the selected path flavour and applies glob semantics without reading the filesystem. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the the whole-path question example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
p=PurePath('a/b.py')
print(p.full_match('a/*.py'))
print(p.full_match('*.py'))

Expected result and reasoning. Python 3.13+ prints True then False: the first pattern covers both components; the second does not cover a/. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating full_match() like a filename-suffix test ignores the parent component. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which path components does the pattern consume from beginning to end?”

• Evidence to collect: the exact input, environment version, observed result and the rule for the whole-path question
• Variable to hold constant: the surrounding setup, so the comparison isolates the whole-path question.
• Variable to change: add the missing a/ component to the second pattern
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For the whole-path question, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a homework archive. Transfer the whole-path question into a homework archive. Preserve the governing rule—The pattern must account for the full path rather than merely a suffix.—while identifying what changes in this setting. full_match() asks whether the entire PurePath matches a glob-style pattern. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The pattern must account for the full path rather than merely a suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a source-tree filter. Transfer the whole-path question into a source-tree filter. Preserve the governing rule—The pattern must account for the full path rather than merely a suffix.—while identifying what changes in this setting. full_match() asks whether the entire PurePath matches a glob-style pattern. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The pattern must account for the full path rather than merely a suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a Windows family computer. Transfer the whole-path question into a Windows family computer. Preserve the governing rule—The pattern must account for the full path rather than merely a suffix.—while identifying what changes in this setting. full_match() asks whether the entire PurePath matches a glob-style pattern. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The pattern must account for the full path rather than merely a suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a packaging script. Transfer the whole-path question into a packaging script. Preserve the governing rule—The pattern must account for the full path rather than merely a suffix.—while identifying what changes in this setting. full_match() asks whether the entire PurePath matches a glob-style pattern. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The pattern must account for the full path rather than merely a suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for the whole-path question, predict the result, then add the missing a/ component to the second pattern. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Python 3.13+ prints True then False: the first pattern covers both components; the second does not cover a/. The contrast is explained by this rule: The pattern must account for the full path rather than merely a suffix. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for the whole-path question, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain the whole-path question, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Contents · Full contents · Next: A lexical operation, not a disk query →

CHAPTER 2 OF 20 · Back to contents

2. A lexical operation, not a disk query

The short answer: PurePath.full_match() evaluates path spelling and flavour only. The governing rule is: No file, directory or permission must exist for a lexical match.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

PurePath deliberately separates path-language reasoning from concrete filesystem calls. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the a lexical operation, not a disk query example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
p=PurePath('imaginary/folder/report.csv')
print(p.full_match('imaginary/**/*.csv'))

Expected result and reasoning. The result is True on Python 3.13+ even if no such path exists. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling exists() first changes the question from pattern classification to environmental state. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does the task ask what the path string means or whether a live object exists?”

• Evidence to collect: the exact input, environment version, observed result and the rule for a lexical operation, not a disk query
• Variable to hold constant: the surrounding setup, so the comparison isolates a lexical operation, not a disk query.
• Variable to change: replace the invented path with another nonexistent spelling
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For a lexical operation, not a disk query, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a cross-platform class project. Transfer a lexical operation, not a disk query into a cross-platform class project. Preserve the governing rule—No file, directory or permission must exist for a lexical match.—while identifying what changes in this setting. PurePath.full_match() evaluates path spelling and flavour only. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “No file, directory or permission must exist for a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a configuration allow-list. Transfer a lexical operation, not a disk query into a configuration allow-list. Preserve the governing rule—No file, directory or permission must exist for a lexical match.—while identifying what changes in this setting. PurePath.full_match() evaluates path spelling and flavour only. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “No file, directory or permission must exist for a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a school-managed laptop. Transfer a lexical operation, not a disk query into a school-managed laptop. Preserve the governing rule—No file, directory or permission must exist for a lexical match.—while identifying what changes in this setting. PurePath.full_match() evaluates path spelling and flavour only. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “No file, directory or permission must exist for a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a code-review checklist. Transfer a lexical operation, not a disk query into a code-review checklist. Preserve the governing rule—No file, directory or permission must exist for a lexical match.—while identifying what changes in this setting. PurePath.full_match() evaluates path spelling and flavour only. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “No file, directory or permission must exist for a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for a lexical operation, not a disk query, predict the result, then replace the invented path with another nonexistent spelling. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The result is True on Python 3.13+ even if no such path exists. The contrast is explained by this rule: No file, directory or permission must exist for a lexical match. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for a lexical operation, not a disk query, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain a lexical operation, not a disk query, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: The whole-path question · Full contents · Next: Relative paths and relative patterns →

CHAPTER 3 OF 20 · Back to contents

3. Relative paths and relative patterns

The short answer: A relative path can be matched by a relative pattern from its beginning. The governing rule is: Full matching does not right-match an arbitrary suffix.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Unlike PurePath.match(), full_match() accounts for every component in the relative path. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the relative paths and relative patterns example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
p=PurePath('src/app/main.py')
print(p.full_match('src/**/*.py'))
print(p.full_match('app/*.py'))

Expected result and reasoning. The first is True and the second False because src is unconsumed by the shorter pattern. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming any visible suffix is enough imports match() behaviour into full_match(). This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is there an unmatched leading component?”

• Evidence to collect: the exact input, environment version, observed result and the rule for relative paths and relative patterns
• Variable to hold constant: the surrounding setup, so the comparison isolates relative paths and relative patterns.
• Variable to change: change app/*.py to src/app/*.py
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For relative paths and relative patterns, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a source-tree filter. Transfer relative paths and relative patterns into a source-tree filter. Preserve the governing rule—Full matching does not right-match an arbitrary suffix.—while identifying what changes in this setting. A relative path can be matched by a relative pattern from its beginning. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Full matching does not right-match an arbitrary suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a Windows family computer. Transfer relative paths and relative patterns into a Windows family computer. Preserve the governing rule—Full matching does not right-match an arbitrary suffix.—while identifying what changes in this setting. A relative path can be matched by a relative pattern from its beginning. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Full matching does not right-match an arbitrary suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a packaging script. Transfer relative paths and relative patterns into a packaging script. Preserve the governing rule—Full matching does not right-match an arbitrary suffix.—while identifying what changes in this setting. A relative path can be matched by a relative pattern from its beginning. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Full matching does not right-match an arbitrary suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a homework archive. Transfer relative paths and relative patterns into a homework archive. Preserve the governing rule—Full matching does not right-match an arbitrary suffix.—while identifying what changes in this setting. A relative path can be matched by a relative pattern from its beginning. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Full matching does not right-match an arbitrary suffix.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for relative paths and relative patterns, predict the result, then change app/*.py to src/app/*.py. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The first is True and the second False because src is unconsumed by the shorter pattern. The contrast is explained by this rule: Full matching does not right-match an arbitrary suffix. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for relative paths and relative patterns, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain relative paths and relative patterns, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: A lexical operation, not a disk query · Full contents · Next: Absolute paths need anchored thinking →

CHAPTER 4 OF 20 · Back to contents

4. Absolute paths need anchored thinking

The short answer: An absolute pattern can describe an absolute path from its root. The governing rule is: The root or drive participates in the full match.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Path flavour determines how roots, drives and separators are represented before glob components are compared. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the absolute paths need anchored thinking example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePosixPath
p=PurePosixPath('/a/b/c.py')
print(p.full_match('/a/**'))

Expected result and reasoning. The documented Python example returns True. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Dropping the leading slash silently changes an anchored absolute pattern into a relative recursive pattern. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Are the path and intended pattern both anchored?”

• Evidence to collect: the exact input, environment version, observed result and the rule for absolute paths need anchored thinking
• Variable to hold constant: the surrounding setup, so the comparison isolates absolute paths need anchored thinking.
• Variable to change: remove the leading slash and explain the different intent
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For absolute paths need anchored thinking, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a configuration allow-list. Transfer absolute paths need anchored thinking into a configuration allow-list. Preserve the governing rule—The root or drive participates in the full match.—while identifying what changes in this setting. An absolute pattern can describe an absolute path from its root. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The root or drive participates in the full match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a school-managed laptop. Transfer absolute paths need anchored thinking into a school-managed laptop. Preserve the governing rule—The root or drive participates in the full match.—while identifying what changes in this setting. An absolute pattern can describe an absolute path from its root. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The root or drive participates in the full match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a code-review checklist. Transfer absolute paths need anchored thinking into a code-review checklist. Preserve the governing rule—The root or drive participates in the full match.—while identifying what changes in this setting. An absolute pattern can describe an absolute path from its root. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The root or drive participates in the full match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a cross-platform class project. Transfer absolute paths need anchored thinking into a cross-platform class project. Preserve the governing rule—The root or drive participates in the full match.—while identifying what changes in this setting. An absolute pattern can describe an absolute path from its root. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The root or drive participates in the full match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for absolute paths need anchored thinking, predict the result, then remove the leading slash and explain the different intent. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The documented Python example returns True. The contrast is explained by this rule: The root or drive participates in the full match. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for absolute paths need anchored thinking, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain absolute paths need anchored thinking, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Relative paths and relative patterns · Full contents · Next: Single-star segment boundaries →

CHAPTER 5 OF 20 · Back to contents

5. Single-star segment boundaries

The short answer: A single star matches characters within one path segment. The governing rule is: * does not consume a separator.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Glob matching works component by component, so a one-level pattern cannot jump across nested directories. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the single-star segment boundaries example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
print(PurePath('a/b.py').full_match('a/*.py'))
print(PurePath('a/x/b.py').full_match('a/*.py'))

Expected result and reasoning. The results are True then False. The nested x/ requires another component or recursive wildcard. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Reading * as arbitrary text across slashes makes shallow allow-lists unexpectedly broad. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “How many segments stand between a/ and the filename?”

• Evidence to collect: the exact input, environment version, observed result and the rule for single-star segment boundaries
• Variable to hold constant: the surrounding setup, so the comparison isolates single-star segment boundaries.
• Variable to change: replace * with ** for the nested case
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For single-star segment boundaries, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a Windows family computer. Transfer single-star segment boundaries into a Windows family computer. Preserve the governing rule—* does not consume a separator.—while identifying what changes in this setting. A single star matches characters within one path segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “* does not consume a separator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a packaging script. Transfer single-star segment boundaries into a packaging script. Preserve the governing rule—* does not consume a separator.—while identifying what changes in this setting. A single star matches characters within one path segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “* does not consume a separator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a homework archive. Transfer single-star segment boundaries into a homework archive. Preserve the governing rule—* does not consume a separator.—while identifying what changes in this setting. A single star matches characters within one path segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “* does not consume a separator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a source-tree filter. Transfer single-star segment boundaries into a source-tree filter. Preserve the governing rule—* does not consume a separator.—while identifying what changes in this setting. A single star matches characters within one path segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “* does not consume a separator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for single-star segment boundaries, predict the result, then replace * with ** for the nested case. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The results are True then False. The nested x/ requires another component or recursive wildcard. The contrast is explained by this rule: * does not consume a separator. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for single-star segment boundaries, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain single-star segment boundaries, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Absolute paths need anchored thinking · Full contents · Next: Recursive double-star →

CHAPTER 6 OF 20 · Back to contents

6. Recursive double-star

The short answer: The recursive wildcard can span directory depth. The governing rule is: ** is the recursive path-component wildcard in full_match().. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The matcher can consume zero or more components where recursive syntax is valid, allowing one policy to cover changing depth. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the recursive double-star example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
for s in ['a/b.py','a/x/b.py','a/x/y/b.py']:
    print(PurePath(s).full_match('a/**/*.py'))

Expected result and reasoning. All three are expected to match on Python 3.13+ because ** covers the intervening depth. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using ** without considering the anchor can authorise more of a tree than intended. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What is fixed before and after the recursive portion?”

• Evidence to collect: the exact input, environment version, observed result and the rule for recursive double-star
• Variable to hold constant: the surrounding setup, so the comparison isolates recursive double-star.
• Variable to change: change the fixed prefix from a to tests
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For recursive double-star, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a school-managed laptop. Transfer recursive double-star into a school-managed laptop. Preserve the governing rule—** is the recursive path-component wildcard in full_match().—while identifying what changes in this setting. The recursive wildcard can span directory depth. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “** is the recursive path-component wildcard in full_match().”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a code-review checklist. Transfer recursive double-star into a code-review checklist. Preserve the governing rule—** is the recursive path-component wildcard in full_match().—while identifying what changes in this setting. The recursive wildcard can span directory depth. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “** is the recursive path-component wildcard in full_match().”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a cross-platform class project. Transfer recursive double-star into a cross-platform class project. Preserve the governing rule—** is the recursive path-component wildcard in full_match().—while identifying what changes in this setting. The recursive wildcard can span directory depth. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “** is the recursive path-component wildcard in full_match().”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a configuration allow-list. Transfer recursive double-star into a configuration allow-list. Preserve the governing rule—** is the recursive path-component wildcard in full_match().—while identifying what changes in this setting. The recursive wildcard can span directory depth. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “** is the recursive path-component wildcard in full_match().”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for recursive double-star, predict the result, then change the fixed prefix from a to tests. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. All three are expected to match on Python 3.13+ because ** covers the intervening depth. The contrast is explained by this rule: ** is the recursive path-component wildcard in full_match(). The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for recursive double-star, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain recursive double-star, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Single-star segment boundaries · Full contents · Next: Question-mark width →

CHAPTER 7 OF 20 · Back to contents

7. Question-mark width

The short answer: A question mark matches one character inside a segment. The governing rule is: ? expresses exactly one non-separator character.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

This makes it useful for fixed-width filename families but unsuitable for an arbitrary identifier. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the question-mark width example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
for s in ['q1.py','q12.py','qa.py']:
    print(PurePath(s).full_match('q?.py'))

Expected result and reasoning. q1.py and qa.py match; q12.py does not because two characters occupy the wildcard position. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating ? as an optional character confuses glob syntax with some regular-expression conventions. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the wildcard one required character or an optional one?”

• Evidence to collect: the exact input, environment version, observed result and the rule for question-mark width
• Variable to hold constant: the surrounding setup, so the comparison isolates question-mark width.
• Variable to change: compare q?.py with q*.py
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For question-mark width, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a packaging script. Transfer question-mark width into a packaging script. Preserve the governing rule—? expresses exactly one non-separator character.—while identifying what changes in this setting. A question mark matches one character inside a segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “? expresses exactly one non-separator character.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a homework archive. Transfer question-mark width into a homework archive. Preserve the governing rule—? expresses exactly one non-separator character.—while identifying what changes in this setting. A question mark matches one character inside a segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “? expresses exactly one non-separator character.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a source-tree filter. Transfer question-mark width into a source-tree filter. Preserve the governing rule—? expresses exactly one non-separator character.—while identifying what changes in this setting. A question mark matches one character inside a segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “? expresses exactly one non-separator character.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a Windows family computer. Transfer question-mark width into a Windows family computer. Preserve the governing rule—? expresses exactly one non-separator character.—while identifying what changes in this setting. A question mark matches one character inside a segment. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “? expresses exactly one non-separator character.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for question-mark width, predict the result, then compare q?.py with q*.py. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. q1.py and qa.py match; q12.py does not because two characters occupy the wildcard position. The contrast is explained by this rule: ? expresses exactly one non-separator character. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for question-mark width, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain question-mark width, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Recursive double-star · Full contents · Next: Character classes →

CHAPTER 8 OF 20 · Back to contents

8. Character classes

The short answer: Square brackets constrain one character to a set or range. The governing rule is: A class still occupies one character position within a segment.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The matcher evaluates the chosen character against the class before continuing with the remaining literal suffix. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the character classes example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
for s in ['unit1.py','unit7.py','unitx.py']:
    print(PurePath(s).full_match('unit[0-9].py'))

Expected result and reasoning. The numeric one-character names match; unitx.py does not. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using [0-9] as if it meant an arbitrary-length integer accepts a false mental model. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “How many characters does the class consume?”

• Evidence to collect: the exact input, environment version, observed result and the rule for character classes
• Variable to hold constant: the surrounding setup, so the comparison isolates character classes.
• Variable to change: test unit12.py as the near miss
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For character classes, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a code-review checklist. Transfer character classes into a code-review checklist. Preserve the governing rule—A class still occupies one character position within a segment.—while identifying what changes in this setting. Square brackets constrain one character to a set or range. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A class still occupies one character position within a segment.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a cross-platform class project. Transfer character classes into a cross-platform class project. Preserve the governing rule—A class still occupies one character position within a segment.—while identifying what changes in this setting. Square brackets constrain one character to a set or range. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A class still occupies one character position within a segment.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a configuration allow-list. Transfer character classes into a configuration allow-list. Preserve the governing rule—A class still occupies one character position within a segment.—while identifying what changes in this setting. Square brackets constrain one character to a set or range. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A class still occupies one character position within a segment.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a school-managed laptop. Transfer character classes into a school-managed laptop. Preserve the governing rule—A class still occupies one character position within a segment.—while identifying what changes in this setting. Square brackets constrain one character to a set or range. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A class still occupies one character position within a segment.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for character classes, predict the result, then test unit12.py as the near miss. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The numeric one-character names match; unitx.py does not. The contrast is explained by this rule: A class still occupies one character position within a segment. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for character classes, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain character classes, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Question-mark width · Full contents · Next: Literal punctuation and extensions →

CHAPTER 9 OF 20 · Back to contents

9. Literal punctuation and extensions

The short answer: Dots in a glob-style pattern are ordinary literal dots. The governing rule is: Glob syntax is not regular-expression syntax.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Characters have glob meanings defined by the pattern language; a dot does not need regex-style escaping for an extension. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the literal punctuation and extensions example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
print(PurePath('notes.v2.md').full_match('*.md'))
print(PurePath('notes.v2.md').full_match('*.py'))

Expected result and reasoning. The markdown pattern is True and the Python pattern False. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Adding regex anchors or backslash habits can create an invalid or unintended glob. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Am I writing a glob or a regular expression?”

• Evidence to collect: the exact input, environment version, observed result and the rule for literal punctuation and extensions
• Variable to hold constant: the surrounding setup, so the comparison isolates literal punctuation and extensions.
• Variable to change: replace only the literal extension
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For literal punctuation and extensions, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a homework archive. Transfer literal punctuation and extensions into a homework archive. Preserve the governing rule—Glob syntax is not regular-expression syntax.—while identifying what changes in this setting. Dots in a glob-style pattern are ordinary literal dots. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Glob syntax is not regular-expression syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a source-tree filter. Transfer literal punctuation and extensions into a source-tree filter. Preserve the governing rule—Glob syntax is not regular-expression syntax.—while identifying what changes in this setting. Dots in a glob-style pattern are ordinary literal dots. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Glob syntax is not regular-expression syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a Windows family computer. Transfer literal punctuation and extensions into a Windows family computer. Preserve the governing rule—Glob syntax is not regular-expression syntax.—while identifying what changes in this setting. Dots in a glob-style pattern are ordinary literal dots. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Glob syntax is not regular-expression syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a packaging script. Transfer literal punctuation and extensions into a packaging script. Preserve the governing rule—Glob syntax is not regular-expression syntax.—while identifying what changes in this setting. Dots in a glob-style pattern are ordinary literal dots. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Glob syntax is not regular-expression syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for literal punctuation and extensions, predict the result, then replace only the literal extension. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The markdown pattern is True and the Python pattern False. The contrast is explained by this rule: Glob syntax is not regular-expression syntax. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for literal punctuation and extensions, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain literal punctuation and extensions, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Character classes · Full contents · Next: POSIX default case sensitivity →

CHAPTER 10 OF 20 · Back to contents

10. POSIX default case sensitivity

The short answer: PurePosixPath follows POSIX case-sensitive defaults unless overridden. The governing rule is: With case_sensitive=None, the path flavour supplies the default.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The object flavour, not the host operating system alone, controls this pure-path comparison. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the posix default case sensitivity example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePosixPath
print(PurePosixPath('b.py').full_match('*.PY'))

Expected result and reasoning. The documented result is False. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Lowercasing both sides outside the API hides the policy choice and can mishandle nontrivial names. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which PurePath flavour provides the default?”

• Evidence to collect: the exact input, environment version, observed result and the rule for posix default case sensitivity
• Variable to hold constant: the surrounding setup, so the comparison isolates posix default case sensitivity.
• Variable to change: pass case_sensitive=False explicitly
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For posix default case sensitivity, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a cross-platform class project. Transfer posix default case sensitivity into a cross-platform class project. Preserve the governing rule—With case_sensitive=None, the path flavour supplies the default.—while identifying what changes in this setting. PurePosixPath follows POSIX case-sensitive defaults unless overridden. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “With case_sensitive=None, the path flavour supplies the default.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a configuration allow-list. Transfer posix default case sensitivity into a configuration allow-list. Preserve the governing rule—With case_sensitive=None, the path flavour supplies the default.—while identifying what changes in this setting. PurePosixPath follows POSIX case-sensitive defaults unless overridden. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “With case_sensitive=None, the path flavour supplies the default.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a school-managed laptop. Transfer posix default case sensitivity into a school-managed laptop. Preserve the governing rule—With case_sensitive=None, the path flavour supplies the default.—while identifying what changes in this setting. PurePosixPath follows POSIX case-sensitive defaults unless overridden. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “With case_sensitive=None, the path flavour supplies the default.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a code-review checklist. Transfer posix default case sensitivity into a code-review checklist. Preserve the governing rule—With case_sensitive=None, the path flavour supplies the default.—while identifying what changes in this setting. PurePosixPath follows POSIX case-sensitive defaults unless overridden. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “With case_sensitive=None, the path flavour supplies the default.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for posix default case sensitivity, predict the result, then pass case_sensitive=False explicitly. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The documented result is False. The contrast is explained by this rule: With case_sensitive=None, the path flavour supplies the default. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for posix default case sensitivity, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain posix default case sensitivity, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Literal punctuation and extensions · Full contents · Next: Windows default case insensitivity →

CHAPTER 11 OF 20 · Back to contents

11. Windows default case insensitivity

The short answer: PureWindowsPath follows Windows case-insensitive matching defaults. The governing rule is: The same letters can match under Windows flavour and fail under POSIX flavour.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Pure path classes let a learner model a foreign platform without accessing that platform filesystem. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the windows default case insensitivity example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PureWindowsPath
print(PureWindowsPath('b.py').full_match('*.PY'))

Expected result and reasoning. The documented result is True. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming the current Linux or macOS host changes PureWindowsPath semantics misunderstands pure flavours. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What flavour is encoded in the object?”

• Evidence to collect: the exact input, environment version, observed result and the rule for windows default case insensitivity
• Variable to hold constant: the surrounding setup, so the comparison isolates windows default case insensitivity.
• Variable to change: compare the same input with PurePosixPath
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For windows default case insensitivity, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a source-tree filter. Transfer windows default case insensitivity into a source-tree filter. Preserve the governing rule—The same letters can match under Windows flavour and fail under POSIX flavour.—while identifying what changes in this setting. PureWindowsPath follows Windows case-insensitive matching defaults. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same letters can match under Windows flavour and fail under POSIX flavour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a Windows family computer. Transfer windows default case insensitivity into a Windows family computer. Preserve the governing rule—The same letters can match under Windows flavour and fail under POSIX flavour.—while identifying what changes in this setting. PureWindowsPath follows Windows case-insensitive matching defaults. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same letters can match under Windows flavour and fail under POSIX flavour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a packaging script. Transfer windows default case insensitivity into a packaging script. Preserve the governing rule—The same letters can match under Windows flavour and fail under POSIX flavour.—while identifying what changes in this setting. PureWindowsPath follows Windows case-insensitive matching defaults. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same letters can match under Windows flavour and fail under POSIX flavour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a homework archive. Transfer windows default case insensitivity into a homework archive. Preserve the governing rule—The same letters can match under Windows flavour and fail under POSIX flavour.—while identifying what changes in this setting. PureWindowsPath follows Windows case-insensitive matching defaults. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same letters can match under Windows flavour and fail under POSIX flavour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for windows default case insensitivity, predict the result, then compare the same input with PurePosixPath. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The documented result is True. The contrast is explained by this rule: The same letters can match under Windows flavour and fail under POSIX flavour. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for windows default case insensitivity, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain windows default case insensitivity, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: POSIX default case sensitivity · Full contents · Next: Explicit case-sensitive override →

CHAPTER 12 OF 20 · Back to contents

12. Explicit case-sensitive override

The short answer: case_sensitive=True requests exact case behaviour. The governing rule is: An explicit override is clearer than relying on a deployment default when policy requires exact case.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The keyword-only option replaces the flavour default for this call. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the explicit case-sensitive override example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PureWindowsPath
p=PureWindowsPath('Report.PDF')
print(p.full_match('*.pdf', case_sensitive=True))

Expected result and reasoning. The result is False because PDF and pdf differ under the explicit strict policy. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using platform default for a cross-platform validation rule makes acceptance depend on where it runs. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is case a property of the policy or merely the platform default?”

• Evidence to collect: the exact input, environment version, observed result and the rule for explicit case-sensitive override
• Variable to hold constant: the surrounding setup, so the comparison isolates explicit case-sensitive override.
• Variable to change: switch the argument to False
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For explicit case-sensitive override, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a configuration allow-list. Transfer explicit case-sensitive override into a configuration allow-list. Preserve the governing rule—An explicit override is clearer than relying on a deployment default when policy requires exact case.—while identifying what changes in this setting. case_sensitive=True requests exact case behaviour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “An explicit override is clearer than relying on a deployment default when policy requires exact case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a school-managed laptop. Transfer explicit case-sensitive override into a school-managed laptop. Preserve the governing rule—An explicit override is clearer than relying on a deployment default when policy requires exact case.—while identifying what changes in this setting. case_sensitive=True requests exact case behaviour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “An explicit override is clearer than relying on a deployment default when policy requires exact case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a code-review checklist. Transfer explicit case-sensitive override into a code-review checklist. Preserve the governing rule—An explicit override is clearer than relying on a deployment default when policy requires exact case.—while identifying what changes in this setting. case_sensitive=True requests exact case behaviour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “An explicit override is clearer than relying on a deployment default when policy requires exact case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a cross-platform class project. Transfer explicit case-sensitive override into a cross-platform class project. Preserve the governing rule—An explicit override is clearer than relying on a deployment default when policy requires exact case.—while identifying what changes in this setting. case_sensitive=True requests exact case behaviour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “An explicit override is clearer than relying on a deployment default when policy requires exact case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for explicit case-sensitive override, predict the result, then switch the argument to False. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The result is False because PDF and pdf differ under the explicit strict policy. The contrast is explained by this rule: An explicit override is clearer than relying on a deployment default when policy requires exact case. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for explicit case-sensitive override, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain explicit case-sensitive override, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Windows default case insensitivity · Full contents · Next: Explicit case-insensitive override →

CHAPTER 13 OF 20 · Back to contents

13. Explicit case-insensitive override

The short answer: case_sensitive=False allows case differences on any flavour. The governing rule is: State the override where case-insensitive policy is intentional.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The same glob structure is used, but alphabetic comparison ignores case. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the explicit case-insensitive override example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePosixPath
p=PurePosixPath('Report.PDF')
print(p.full_match('*.pdf', case_sensitive=False))

Expected result and reasoning. The result is True. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Mutating the original path string to lowercase can lose the exact value needed for display or auditing. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Can the policy be expressed without changing stored data?”

• Evidence to collect: the exact input, environment version, observed result and the rule for explicit case-insensitive override
• Variable to hold constant: the surrounding setup, so the comparison isolates explicit case-insensitive override.
• Variable to change: remove the override and compare
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For explicit case-insensitive override, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a Windows family computer. Transfer explicit case-insensitive override into a Windows family computer. Preserve the governing rule—State the override where case-insensitive policy is intentional.—while identifying what changes in this setting. case_sensitive=False allows case differences on any flavour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “State the override where case-insensitive policy is intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a packaging script. Transfer explicit case-insensitive override into a packaging script. Preserve the governing rule—State the override where case-insensitive policy is intentional.—while identifying what changes in this setting. case_sensitive=False allows case differences on any flavour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “State the override where case-insensitive policy is intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a homework archive. Transfer explicit case-insensitive override into a homework archive. Preserve the governing rule—State the override where case-insensitive policy is intentional.—while identifying what changes in this setting. case_sensitive=False allows case differences on any flavour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “State the override where case-insensitive policy is intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a source-tree filter. Transfer explicit case-insensitive override into a source-tree filter. Preserve the governing rule—State the override where case-insensitive policy is intentional.—while identifying what changes in this setting. case_sensitive=False allows case differences on any flavour. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “State the override where case-insensitive policy is intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for explicit case-insensitive override, predict the result, then remove the override and compare. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The result is True. The contrast is explained by this rule: State the override where case-insensitive policy is intentional. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for explicit case-insensitive override, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain explicit case-insensitive override, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Explicit case-sensitive override · Full contents · Next: PurePath and concrete Path →

CHAPTER 14 OF 20 · Back to contents

14. PurePath and concrete Path

The short answer: Path inherits lexical matching while also offering filesystem operations. The governing rule is: Calling full_match() on Path still performs a lexical match.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Inheritance does not make this particular method consult disk; its contract remains pure pattern comparison. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the purepath and concrete path example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import Path
p=Path('missing/report.txt')
print(p.full_match('missing/*.txt'))

Expected result and reasoning. On Python 3.13+ the lexical result is True regardless of existence. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming every Path method touches the filesystem ignores the documented method contract. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which method is being called, rather than which broad class name is visible?”

• Evidence to collect: the exact input, environment version, observed result and the rule for purepath and concrete path
• Variable to hold constant: the surrounding setup, so the comparison isolates purepath and concrete path.
• Variable to change: follow with p.exists() and separate the two results
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For purepath and concrete path, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a school-managed laptop. Transfer purepath and concrete path into a school-managed laptop. Preserve the governing rule—Calling full_match() on Path still performs a lexical match.—while identifying what changes in this setting. Path inherits lexical matching while also offering filesystem operations. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Calling full_match() on Path still performs a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a code-review checklist. Transfer purepath and concrete path into a code-review checklist. Preserve the governing rule—Calling full_match() on Path still performs a lexical match.—while identifying what changes in this setting. Path inherits lexical matching while also offering filesystem operations. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Calling full_match() on Path still performs a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a cross-platform class project. Transfer purepath and concrete path into a cross-platform class project. Preserve the governing rule—Calling full_match() on Path still performs a lexical match.—while identifying what changes in this setting. Path inherits lexical matching while also offering filesystem operations. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Calling full_match() on Path still performs a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a configuration allow-list. Transfer purepath and concrete path into a configuration allow-list. Preserve the governing rule—Calling full_match() on Path still performs a lexical match.—while identifying what changes in this setting. Path inherits lexical matching while also offering filesystem operations. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Calling full_match() on Path still performs a lexical match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for purepath and concrete path, predict the result, then follow with p.exists() and separate the two results. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. On Python 3.13+ the lexical result is True regardless of existence. The contrast is explained by this rule: Calling full_match() on Path still performs a lexical match. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for purepath and concrete path, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain purepath and concrete path, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Explicit case-insensitive override · Full contents · Next: full_match() versus match() →

CHAPTER 15 OF 20 · Back to contents

15. full_match() versus match()

The short answer: match() may right-match a relative pattern; full_match() does not. The governing rule is: Choose the method that expresses whole-policy validation versus suffix-oriented matching.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The documented contrast uses the same path and pattern but different anchoring behaviour. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the full_match() versus match() example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
p=PurePath('a/b.py')
print(p.full_match('*.py'))
print(p.match('*.py'))

Expected result and reasoning. Python 3.13+ prints False then True. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Replacing full_match with match just to make a test green weakens the policy. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does the job require the whole relative path or only a right-hand pattern?”

• Evidence to collect: the exact input, environment version, observed result and the rule for full_match() versus match()
• Variable to hold constant: the surrounding setup, so the comparison isolates full_match() versus match().
• Variable to change: prefix a/ in the full-match pattern
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For full_match() versus match(), a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a packaging script. Transfer full_match() versus match() into a packaging script. Preserve the governing rule—Choose the method that expresses whole-policy validation versus suffix-oriented matching.—while identifying what changes in this setting. match() may right-match a relative pattern; full_match() does not. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the method that expresses whole-policy validation versus suffix-oriented matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a homework archive. Transfer full_match() versus match() into a homework archive. Preserve the governing rule—Choose the method that expresses whole-policy validation versus suffix-oriented matching.—while identifying what changes in this setting. match() may right-match a relative pattern; full_match() does not. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the method that expresses whole-policy validation versus suffix-oriented matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a source-tree filter. Transfer full_match() versus match() into a source-tree filter. Preserve the governing rule—Choose the method that expresses whole-policy validation versus suffix-oriented matching.—while identifying what changes in this setting. match() may right-match a relative pattern; full_match() does not. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the method that expresses whole-policy validation versus suffix-oriented matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a Windows family computer. Transfer full_match() versus match() into a Windows family computer. Preserve the governing rule—Choose the method that expresses whole-policy validation versus suffix-oriented matching.—while identifying what changes in this setting. match() may right-match a relative pattern; full_match() does not. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the method that expresses whole-policy validation versus suffix-oriented matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for full_match() versus match(), predict the result, then prefix a/ in the full-match pattern. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Python 3.13+ prints False then True. The contrast is explained by this rule: Choose the method that expresses whole-policy validation versus suffix-oriented matching. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for full_match() versus match(), then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain full_match() versus match(), solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: PurePath and concrete Path · Full contents · Next: Recursive semantics versus match() →

CHAPTER 16 OF 20 · Back to contents

16. Recursive semantics versus match()

The short answer: match() treats ** as non-recursive, while full_match() supports the recursive wildcard. The governing rule is: Do not transfer recursive expectations between the two APIs.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Python documents match() as a non-recursive glob matcher even when double-star spelling appears. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the recursive semantics versus match() example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
p=PurePath('a/x/b.py')
print(p.full_match('a/**/*.py'))
print(p.match('a/**/*.py'))

Expected result and reasoning. The full matcher is designed for the recursive case; match() is not a substitute for that contract. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Seeing the same characters ** and assuming identical semantics ignores the API boundary. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which method defines recursive wildcard support?”

• Evidence to collect: the exact input, environment version, observed result and the rule for recursive semantics versus match()
• Variable to hold constant: the surrounding setup, so the comparison isolates recursive semantics versus match().
• Variable to change: replace ** with an explicit one-level component for match()
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For recursive semantics versus match(), a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a code-review checklist. Transfer recursive semantics versus match() into a code-review checklist. Preserve the governing rule—Do not transfer recursive expectations between the two APIs.—while identifying what changes in this setting. match() treats ** as non-recursive, while full_match() supports the recursive wildcard. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not transfer recursive expectations between the two APIs.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a cross-platform class project. Transfer recursive semantics versus match() into a cross-platform class project. Preserve the governing rule—Do not transfer recursive expectations between the two APIs.—while identifying what changes in this setting. match() treats ** as non-recursive, while full_match() supports the recursive wildcard. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not transfer recursive expectations between the two APIs.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a configuration allow-list. Transfer recursive semantics versus match() into a configuration allow-list. Preserve the governing rule—Do not transfer recursive expectations between the two APIs.—while identifying what changes in this setting. match() treats ** as non-recursive, while full_match() supports the recursive wildcard. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not transfer recursive expectations between the two APIs.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a school-managed laptop. Transfer recursive semantics versus match() into a school-managed laptop. Preserve the governing rule—Do not transfer recursive expectations between the two APIs.—while identifying what changes in this setting. match() treats ** as non-recursive, while full_match() supports the recursive wildcard. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not transfer recursive expectations between the two APIs.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for recursive semantics versus match(), predict the result, then replace ** with an explicit one-level component for match(). Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The full matcher is designed for the recursive case; match() is not a substitute for that contract. The contrast is explained by this rule: Do not transfer recursive expectations between the two APIs. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for recursive semantics versus match(), then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain recursive semantics versus match(), solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: full_match() versus match() · Full contents · Next: Allow-lists before deny-lists →

CHAPTER 17 OF 20 · Back to contents

17. Allow-lists before deny-lists

The short answer: A narrow positive pattern is easier to reason about than a broad match followed by scattered exceptions. The governing rule is: Express the accepted tree, depth and extension directly when possible.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Whole-path matching is especially suitable for small policy tables whose entries can each be tested with positive and negative fixtures. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the allow-lists before deny-lists example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
allowed=['src/**/*.py','tests/**/*.py']
def ok(s): return any(PurePath(s).full_match(p) for p in allowed)
print(ok('src/a.py'), ok('docs/a.py'))

Expected result and reasoning. The source path is accepted and the docs path rejected. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using **/*.py alone silently includes Python files from every subtree. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which prefixes are intentionally authorised?”

• Evidence to collect: the exact input, environment version, observed result and the rule for allow-lists before deny-lists
• Variable to hold constant: the surrounding setup, so the comparison isolates allow-lists before deny-lists.
• Variable to change: add a docs pattern only after an explicit decision
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For allow-lists before deny-lists, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a homework archive. Transfer allow-lists before deny-lists into a homework archive. Preserve the governing rule—Express the accepted tree, depth and extension directly when possible.—while identifying what changes in this setting. A narrow positive pattern is easier to reason about than a broad match followed by scattered exceptions. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Express the accepted tree, depth and extension directly when possible.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a source-tree filter. Transfer allow-lists before deny-lists into a source-tree filter. Preserve the governing rule—Express the accepted tree, depth and extension directly when possible.—while identifying what changes in this setting. A narrow positive pattern is easier to reason about than a broad match followed by scattered exceptions. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Express the accepted tree, depth and extension directly when possible.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a Windows family computer. Transfer allow-lists before deny-lists into a Windows family computer. Preserve the governing rule—Express the accepted tree, depth and extension directly when possible.—while identifying what changes in this setting. A narrow positive pattern is easier to reason about than a broad match followed by scattered exceptions. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Express the accepted tree, depth and extension directly when possible.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a packaging script. Transfer allow-lists before deny-lists into a packaging script. Preserve the governing rule—Express the accepted tree, depth and extension directly when possible.—while identifying what changes in this setting. A narrow positive pattern is easier to reason about than a broad match followed by scattered exceptions. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Express the accepted tree, depth and extension directly when possible.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for allow-lists before deny-lists, predict the result, then add a docs pattern only after an explicit decision. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The source path is accepted and the docs path rejected. The contrast is explained by this rule: Express the accepted tree, depth and extension directly when possible. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for allow-lists before deny-lists, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain allow-lists before deny-lists, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Recursive semantics versus match() · Full contents · Next: Version gate at Python 3.13 →

CHAPTER 18 OF 20 · Back to contents

18. Version gate at Python 3.13

The short answer: PurePath.full_match() was added in Python 3.13. The governing rule is: Check the runtime before relying on the method.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

A source file can be lexically correct yet fail on an older interpreter because the attribute does not exist. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the version gate at python 3.13 example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

import sys
from pathlib import PurePath
print(sys.version_info[:3])
print(hasattr(PurePath('a'), 'full_match'))

Expected result and reasoning. Python 3.13+ reports the method; the independently checked CPython 3.12.14 fixture reports False. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Catching AttributeError and silently accepting every path creates a dangerous compatibility fallback. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What should an older runtime do: fail clearly, upgrade, or use a separately tested compatibility layer?”

• Evidence to collect: the exact input, environment version, observed result and the rule for version gate at python 3.13
• Variable to hold constant: the surrounding setup, so the comparison isolates version gate at python 3.13.
• Variable to change: run the guard under 3.12 and a documented 3.13+ environment
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For version gate at python 3.13, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a cross-platform class project. Transfer version gate at python 3.13 into a cross-platform class project. Preserve the governing rule—Check the runtime before relying on the method.—while identifying what changes in this setting. PurePath.full_match() was added in Python 3.13. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the runtime before relying on the method.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a configuration allow-list. Transfer version gate at python 3.13 into a configuration allow-list. Preserve the governing rule—Check the runtime before relying on the method.—while identifying what changes in this setting. PurePath.full_match() was added in Python 3.13. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the runtime before relying on the method.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a school-managed laptop. Transfer version gate at python 3.13 into a school-managed laptop. Preserve the governing rule—Check the runtime before relying on the method.—while identifying what changes in this setting. PurePath.full_match() was added in Python 3.13. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the runtime before relying on the method.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a code-review checklist. Transfer version gate at python 3.13 into a code-review checklist. Preserve the governing rule—Check the runtime before relying on the method.—while identifying what changes in this setting. PurePath.full_match() was added in Python 3.13. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the runtime before relying on the method.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for version gate at python 3.13, predict the result, then run the guard under 3.12 and a documented 3.13+ environment. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Python 3.13+ reports the method; the independently checked CPython 3.12.14 fixture reports False. The contrast is explained by this rule: Check the runtime before relying on the method. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for version gate at python 3.13, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain version gate at python 3.13, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Allow-lists before deny-lists · Full contents · Next: Table-driven pattern tests →

CHAPTER 19 OF 20 · Back to contents

19. Table-driven pattern tests

The short answer: A policy deserves a matrix of expected True and False cases. The governing rule is: Test boundaries, not only happy paths.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

A table makes prefixes, depth, extension and case policy visible and reviewable. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the table-driven pattern tests example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

cases=[('src/a.py','src/**/*.py',True),('docs/a.py','src/**/*.py',False)]
# Python 3.13+
from pathlib import PurePath
for s,pat,want in cases:
    assert PurePath(s).full_match(pat)==want

Expected result and reasoning. Both assertions pass when the policy and expectations agree. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. One demonstration cannot reveal whether the pattern is accidentally too broad. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which near misses challenge each wildcard or anchor?”

• Evidence to collect: the exact input, environment version, observed result and the rule for table-driven pattern tests
• Variable to hold constant: the surrounding setup, so the comparison isolates table-driven pattern tests.
• Variable to change: add nested, uppercase and wrong-extension rows
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For table-driven pattern tests, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a source-tree filter. Transfer table-driven pattern tests into a source-tree filter. Preserve the governing rule—Test boundaries, not only happy paths.—while identifying what changes in this setting. A policy deserves a matrix of expected True and False cases. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Test boundaries, not only happy paths.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a Windows family computer. Transfer table-driven pattern tests into a Windows family computer. Preserve the governing rule—Test boundaries, not only happy paths.—while identifying what changes in this setting. A policy deserves a matrix of expected True and False cases. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Test boundaries, not only happy paths.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a packaging script. Transfer table-driven pattern tests into a packaging script. Preserve the governing rule—Test boundaries, not only happy paths.—while identifying what changes in this setting. A policy deserves a matrix of expected True and False cases. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Test boundaries, not only happy paths.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a homework archive. Transfer table-driven pattern tests into a homework archive. Preserve the governing rule—Test boundaries, not only happy paths.—while identifying what changes in this setting. A policy deserves a matrix of expected True and False cases. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Test boundaries, not only happy paths.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for table-driven pattern tests, predict the result, then add nested, uppercase and wrong-extension rows. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Both assertions pass when the policy and expectations agree. The contrast is explained by this rule: Test boundaries, not only happy paths. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for table-driven pattern tests, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain table-driven pattern tests, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Version gate at Python 3.13 · Full contents · Next: Choosing full_match() for the right job →

CHAPTER 20 OF 20 · Back to contents

20. Choosing full_match() for the right job

The short answer: Use full_match() for lexical, whole-path glob validation in Python 3.13+. The governing rule is: Use filesystem queries, regular expressions or match() when those different contracts are actually required.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Tool choice depends on whether the input is a path abstraction, whether full anchoring matters and whether glob syntax expresses the policy cleanly. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the choosing full_match() for the right job example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

from pathlib import PurePath
def is_python_source(name):
    return PurePath(name).full_match('src/**/*.py', case_sensitive=True)

Expected result and reasoning. The helper states a narrow lexical contract and can be tested without disk access. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling it a security boundary without normalisation, trusted roots and filesystem checks overstates what lexical matching proves. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What stronger environmental guarantees does the application need beyond a glob match?”

• Evidence to collect: the exact input, environment version, observed result and the rule for choosing full_match() for the right job
• Variable to hold constant: the surrounding setup, so the comparison isolates choosing full_match() for the right job.
• Variable to change: compare a lexical classifier with an authorised filesystem traversal
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For choosing full_match() for the right job, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a configuration allow-list. Transfer choosing full_match() for the right job into a configuration allow-list. Preserve the governing rule—Use filesystem queries, regular expressions or match() when those different contracts are actually required.—while identifying what changes in this setting. Use full_match() for lexical, whole-path glob validation in Python 3.13+. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use filesystem queries, regular expressions or match() when those different contracts are actually required.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a school-managed laptop. Transfer choosing full_match() for the right job into a school-managed laptop. Preserve the governing rule—Use filesystem queries, regular expressions or match() when those different contracts are actually required.—while identifying what changes in this setting. Use full_match() for lexical, whole-path glob validation in Python 3.13+. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use filesystem queries, regular expressions or match() when those different contracts are actually required.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a code-review checklist. Transfer choosing full_match() for the right job into a code-review checklist. Preserve the governing rule—Use filesystem queries, regular expressions or match() when those different contracts are actually required.—while identifying what changes in this setting. Use full_match() for lexical, whole-path glob validation in Python 3.13+. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use filesystem queries, regular expressions or match() when those different contracts are actually required.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a cross-platform class project. Transfer choosing full_match() for the right job into a cross-platform class project. Preserve the governing rule—Use filesystem queries, regular expressions or match() when those different contracts are actually required.—while identifying what changes in this setting. Use full_match() for lexical, whole-path glob validation in Python 3.13+. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use filesystem queries, regular expressions or match() when those different contracts are actually required.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for choosing full_match() for the right job, predict the result, then compare a lexical classifier with an authorised filesystem traversal. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The helper states a narrow lexical contract and can be tested without disk access. The contrast is explained by this rule: Use filesystem queries, regular expressions or match() when those different contracts are actually required. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for choosing full_match() for the right job, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain choosing full_match() for the right job, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Table-driven pattern tests · Full contents · Parent guide →

Parent guide: what mastery looks like

A learner has not mastered Python pathlib.PurePath.full_match merely because one polished example runs. Look for four behaviours: they can state the rule in plain language; predict before executing; isolate one changed condition; and explain why a transfer case is the same problem or a different one. Those behaviours make progress visible without requiring a parent to become a specialist.

Use a ten-minute check-in. Ask the learner to choose one chapter, reconstruct its example from memory, and narrate the causal chain. Then change one input. If the learner can update the prediction and justify the change, stop. More repetitions are not automatically better. Save the two-case pair and return to it after a few days.

If every answer is hesitant, reduce the scope. Return to the earliest chapter whose rule cannot be stated accurately. If explanations are fluent but real tasks still fail, move to a capstone because the missing skill is likely transfer or diagnosis. If frustration rises, separate typing errors from conceptual errors and solve only one category in that session.

Capstone practice with explained routes

Capstone 1: Rebuild the smallest trustworthy fixture

Scenario. Create a disposable Python fixture that demonstrates whole-path glob matching without unrelated project code.

Route. Record environment, input, prediction and output. Keep one nearby contrast. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The fixture succeeds when another learner can reproduce the observation and explain the rule separating the two cases. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 2: Diagnose a believable wrong explanation

Scenario. A learner has the correct output but explains it with the wrong mechanism.

Route. Change the one condition the wrong explanation says matters while holding the real governing condition constant. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The controlled contrast exposes the misconception without turning the task into guesswork. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 3: Handle a version boundary

Scenario. Two environments produce different observations.

Route. Capture versions, platform or browser, exact input and relevant state before comparing. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A difference is not automatically an error; bind the claim to the documented environment and retest. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 4: Design a parent check-in

Scenario. A parent has ten minutes and no specialist background.

Route. Ask for one rule, one prediction, one run and one changed condition. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The learner demonstrates mastery through a causal explanation and evidence-based revision. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 5: Transfer into a larger project

Scenario. The isolated fixture works but a school or home project does not.

Route. Preserve the fixture, then compare project inputs and dependencies one at a time. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The first dependency that changes the result becomes the next diagnostic focus; the verified rule remains the baseline. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 6: Write a regression check

Scenario. The behaviour must remain understood after an update.

Route. Save the smallest positive case, the near miss and version metadata. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A useful check reports a meaningful changed observation and points back to the governing rule. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 7: Explain a limitation honestly

Scenario. The selected feature does not cover an important job or is not universally available.

Route. Name the limitation, show what evidence the feature provides and identify the safer route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Good advice is bounded; it neither discards a useful tool nor stretches it into a guarantee. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 8: Choose the right tool

Scenario. Several related methods or commands appear to solve the same task.

Route. Define desired output, evaluation timing, compatibility and acceptable failure modes. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Select the contract that matches the job and state why at least one tempting alternative was rejected. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Frequently asked questions

Is Python pathlib.PurePath.full_match mainly a syntax topic?

No. Syntax is only the handle. Mastery means stating the contract, predicting boundary cases, collecting the right evidence, and choosing a safer or more suitable tool when the contract does not fit.

How long should one practice session be?

Ten to twenty focused minutes is enough for one rule, one worked example, one near miss and one explanation. Stop when the learner can explain the contrast; preserve the fixture for later retrieval.

Should every edge case be memorised?

No. Memorise the central rule and organise edge cases by cause: version, platform, input type, browser support, database schema or repository state. Keep the primary source beside the fixture.

What can a non-specialist parent ask?

Ask for a prediction, the rule behind it, the observation that could disprove it and one changed case. Those questions reveal understanding without requiring the parent to know the command or final value.

When is copying an example useful?

Copying establishes a trusted baseline. It becomes learning after the student predicts the result, reconstructs the example, changes one condition and explains the changed outcome.

How do we separate setup errors from concept errors?

Run a known-good minimal fixture first. If it fails, inspect version, support and transcription. If it passes but the learner predicts a controlled variation incorrectly, the misconception is conceptual.

Should practice start inside a large project?

Not initially. Begin in a disposable directory, tiny script, isolated HTML file or in-memory database. Transfer the verified rule only after the smallest case is understood.

What belongs in revision notes?

Keep the rule in one sentence, the smallest successful example, a near miss, observed output, environment version and one diagnostic question. This is more reusable than copied pages of prose.

What if two computers disagree?

Treat the difference as evidence. Record versions, operating system or browser, exact input and relevant state. Then consult the versioned primary source before deciding that either observation is wrong.

When should the learner move on?

Move on when the learner can explain the rule, predict two contrasts, diagnose a deliberately broken case and transfer the idea to a fresh context without step-by-step prompting.

References and verification notes

Primary technical source: Python pathlib documentation for PurePath.full_match(). The official documentation defines whole-path glob matching, recursive examples, platform case defaults, the override and the Python 3.13 version boundary.

The worked examples were checked with the official Python 3.15 examples plus independent component-by-component prediction tables; the available CPython 3.12.14 runtime was used to confirm the pre-3.13 absence and is not misrepresented as executing full_match(). The checks confirm the specific examples in this guide; they do not promise identical behaviour on an older version, a different operating system, a different browser implementation, or a repository with different state. Keep the version and environment with the saved fixture.

Last reviewed: 17 October 2026. This article is educational guidance for families and learners. It does not advertise a physical Punggol outlet or make admissions, affiliation, score or outcome guarantees.