When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.

Python tomllib parses TOML configuration data into ordinary Python objects. It entered the standard library in Python 3.11, reads a binary file with tomllib.load() or a string with tomllib.loads(), raises TOMLDecodeError for invalid documents, and deliberately does not write TOML. Mastery means separating syntax validity from application validation, predicting the Python type produced for each TOML value, choosing a float policy deliberately, limiting untrusted input, and knowing when a style-preserving editor or writer is the actual tool required. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.

Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.

Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.

The standard-library module turns TOML input into Python data and intentionally provides no dump or dumps function. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is planning a round-trip editor around an API that cannot preserve or emit TOML. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for tomllib parses but does not write TOML, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the tomllib parses but does not write TOML chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on planning a round-trip editor around an API that cannot preserve or emit TOML. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
print(hasattr(tomllib,'loads'),hasattr(tomllib,'dumps'))

Four purposeful transfer cases

Case 1: homework app. Predict the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading tracker. Contrast the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science project. Stress-test the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA website. Explain the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers planning a round-trip editor around an API that cannot preserve or emit TOML.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for tomllib parses but does not write TOML, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from tomllib parses but does not write TOML?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing planning a round-trip editor around an API that cannot preserve or emit TOML be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library catalogue with quoted keys, dotted keys and date values expose conversion boundaries. Include one ordinary case, one boundary and one deliberate failure caused by planning a round-trip editor around an API that cannot preserve or emit TOML. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For tomllib parses but does not write TOML, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

tomllib was added to the standard library in Python 3.11, while older supported applications need an explicit dependency or version gate. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is testing on a new laptop and assuming every deployment interpreter includes the module. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Python 3.11 is the module boundary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Python 3.11 is the module boundary chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on testing on a new laptop and assuming every deployment interpreter includes the module. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import sys
print(sys.version_info[:2])
import tomllib

Four purposeful transfer cases

Case 1: science project. Contrast the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA website. Stress-test the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family planner. Explain the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library catalogue. Transfer the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers testing on a new laptop and assuming every deployment interpreter includes the module.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Python 3.11 is the module boundary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Python 3.11 is the module boundary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing on a new laptop and assuming every deployment interpreter includes the module be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with invalid syntax, wrong file mode, large input and schema mismatches are isolated. Include one ordinary case, one boundary and one deliberate failure caused by testing on a new laptop and assuming every deployment interpreter includes the module. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Python 3.11 is the module boundary, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

tomllib.load expects a readable binary file object as its positional input. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is opening the file in text mode because the resulting content looks like text. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for load reads a binary file object, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the load reads a binary file object chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on opening the file in text mode because the resulting content looks like text. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

from pathlib import Path
import tomllib
with Path('pyproject.toml').open('rb') as f:
 data=tomllib.load(f)

Four purposeful transfer cases

Case 1: family planner. Stress-test the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library catalogue. Explain the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Transfer the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Predict the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers opening the file in text mode because the resulting content looks like text.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for load reads a binary file object, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from load reads a binary file object?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing opening the file in text mode because the resulting content looks like text be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. Include one ordinary case, one boundary and one deliberate failure caused by opening the file in text mode because the resulting content looks like text. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For load reads a binary file object, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

tomllib.loads accepts TOML held in a str and returns a dictionary. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is encoding a string to bytes before calling loads. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for loads reads a Python string, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the loads reads a Python string chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on encoding a string to bytes before calling loads. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
data=tomllib.loads('title = "Punggol plan"')
print(data['title'])

Four purposeful transfer cases

Case 1: test laboratory. Explain the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Transfer the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework app. Predict the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading tracker. Contrast the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers encoding a string to bytes before calling loads.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for loads reads a Python string, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from loads reads a Python string?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing encoding a string to bytes before calling loads be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework app with a project.toml file stores subject names, due dates and feature flags. Include one ordinary case, one boundary and one deliberate failure caused by encoding a string to bytes before calling loads. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For loads reads a Python string, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

TOML tables become nested dictionaries while keys identify the route through the result. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting attribute access such as data.project.name on ordinary dictionaries. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for The result is a nested dictionary model, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the The result is a nested dictionary model chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting attribute access such as data.project.name on ordinary dictionaries. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
data=tomllib.loads('[project]
name="Map"')
print(data['project']['name'])

Four purposeful transfer cases

Case 1: homework app. Transfer the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading tracker. Predict the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science project. Contrast the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA website. Stress-test the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting attribute access such as data.project.name on ordinary dictionaries.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for The result is a nested dictionary model, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from The result is a nested dictionary model?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting attribute access such as data.project.name on ordinary dictionaries be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading tracker with a TOML string describes books, page targets and review dates. Include one ordinary case, one boundary and one deliberate failure caused by expecting attribute access such as data.project.name on ordinary dictionaries. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The result is a nested dictionary model, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A TOML array becomes a Python list whose element values follow TOML conversion rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating the result as an immutable tuple or a comma-separated string. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Arrays preserve ordered values, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Arrays preserve ordered values chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating the result as an immutable tuple or a comma-separated string. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
data=tomllib.loads('levels=[1,2,3]')
print(data['levels'],type(data['levels']).__name__)

Four purposeful transfer cases

Case 1: science project. Predict the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA website. Contrast the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family planner. Stress-test the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library catalogue. Explain the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating the result as an immutable tuple or a comma-separated string.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Arrays preserve ordered values, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Arrays preserve ordered values?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating the result as an immutable tuple or a comma-separated string be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science project with measurements require Decimal conversion rather than binary floating point. Include one ordinary case, one boundary and one deliberate failure caused by treating the result as an immutable tuple or a comma-separated string. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Arrays preserve ordered values, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Double-bracket table declarations represent repeated table entries and parse as a list of dictionaries. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using several parallel arrays and losing the relationship between each record’s fields. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Arrays of tables become lists of records, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Arrays of tables become lists of records chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using several parallel arrays and losing the relationship between each record’s fields. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
s='[[book]]
title="A"
[[book]]
title="B"'
print(tomllib.loads(s)['book'])

Four purposeful transfer cases

Case 1: family planner. Contrast the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library catalogue. Stress-test the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Explain the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Transfer the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using several parallel arrays and losing the relationship between each record’s fields.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Arrays of tables become lists of records, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Arrays of tables become lists of records?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using several parallel arrays and losing the relationship between each record’s fields be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA website with nested tables organise event venue, roles and contact settings. Include one ordinary case, one boundary and one deliberate failure caused by using several parallel arrays and losing the relationship between each record’s fields. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Arrays of tables become lists of records, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A dotted key defines a path of nested keys under TOML’s key rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is splitting every dot in every quoted key after parsing. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Dotted keys create nested structure, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Dotted keys create nested structure chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on splitting every dot in every quoted key after parsing. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
print(tomllib.loads('school.level = 2'))

Four purposeful transfer cases

Case 1: test laboratory. Stress-test the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Explain the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework app. Transfer the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading tracker. Predict the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers splitting every dot in every quoted key after parsing.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Dotted keys create nested structure, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Dotted keys create nested structure?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing splitting every dot in every quoted key after parsing be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with arrays of tables represent several appointments without inventing parallel lists. Include one ordinary case, one boundary and one deliberate failure caused by splitting every dot in every quoted key after parsing. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Dotted keys create nested structure, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Quoted TOML keys preserve characters that would otherwise act as key syntax. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming every dot in a key always means another dictionary level. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Quoted keys can contain punctuation, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Quoted keys can contain punctuation chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming every dot in a key always means another dictionary level. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
print(tomllib.loads('"school.level" = 2'))

Four purposeful transfer cases

Case 1: homework app. Explain the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading tracker. Transfer the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science project. Predict the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA website. Contrast the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming every dot in a key always means another dictionary level.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Quoted keys can contain punctuation, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Quoted keys can contain punctuation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming every dot in a key always means another dictionary level be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library catalogue with quoted keys, dotted keys and date values expose conversion boundaries. Include one ordinary case, one boundary and one deliberate failure caused by assuming every dot in a key always means another dictionary level. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Quoted keys can contain punctuation, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

TOML true and false become Python bool values, and Python-style capitalised True is not valid TOML. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is copying Python literals into a TOML document. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Booleans are lowercase TOML tokens, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Booleans are lowercase TOML tokens chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on copying Python literals into a TOML document. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
print(tomllib.loads('ready=true')['ready'])

Four purposeful transfer cases

Case 1: science project. Transfer the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA website. Predict the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family planner. Contrast the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library catalogue. Stress-test the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers copying Python literals into a TOML document.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Booleans are lowercase TOML tokens, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Booleans are lowercase TOML tokens?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing copying Python literals into a TOML document be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with invalid syntax, wrong file mode, large input and schema mismatches are isolated. Include one ordinary case, one boundary and one deliberate failure caused by copying Python literals into a TOML document. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Booleans are lowercase TOML tokens, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

TOML integers become int and ordinary TOML floats use the parse_float policy, float by default. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming every numeric value arrives as the same generic number type. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Integers and floats remain distinct conversions, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Integers and floats remain distinct conversions chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming every numeric value arrives as the same generic number type. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
d=tomllib.loads('count=3
ratio=0.3')
print(type(d['count']).__name__,type(d['ratio']).__name__)

Four purposeful transfer cases

Case 1: family planner. Predict the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library catalogue. Contrast the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Stress-test the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Explain the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming every numeric value arrives as the same generic number type.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Integers and floats remain distinct conversions, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Integers and floats remain distinct conversions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming every numeric value arrives as the same generic number type be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. Include one ordinary case, one boundary and one deliberate failure caused by assuming every numeric value arrives as the same generic number type. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Integers and floats remain distinct conversions, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The parse_float callable receives each TOML float token as a string and may return a suitable alternate numeric type such as Decimal. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is converting an already-rounded binary float to Decimal after parsing. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for parse_float can select Decimal, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the parse_float can select Decimal chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on converting an already-rounded binary float to Decimal after parsing. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

from decimal import Decimal
import tomllib
d=tomllib.loads('price=0.10',parse_float=Decimal)
print(d['price'],type(d['price']).__name__)

Four purposeful transfer cases

Case 1: test laboratory. Contrast the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Stress-test the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework app. Explain the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading tracker. Transfer the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers converting an already-rounded binary float to Decimal after parsing.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for parse_float can select Decimal, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from parse_float can select Decimal?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing converting an already-rounded binary float to Decimal after parsing be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework app with a project.toml file stores subject names, due dates and feature flags. Include one ordinary case, one boundary and one deliberate failure caused by converting an already-rounded binary float to Decimal after parsing. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For parse_float can select Decimal, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The documented callback result must not be a dict or list because those types would collide with TOML container structure. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using parse_float as a place to attach arbitrary structured metadata. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for parse_float cannot return a list or dictionary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the parse_float cannot return a list or dictionary chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using parse_float as a place to attach arbitrary structured metadata. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
try: tomllib.loads('x=1.5',parse_float=lambda s:{'raw':s})
except ValueError as e: print(type(e).__name__)

Four purposeful transfer cases

Case 1: homework app. Stress-test the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading tracker. Explain the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science project. Transfer the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA website. Predict the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using parse_float as a place to attach arbitrary structured metadata.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for parse_float cannot return a list or dictionary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from parse_float cannot return a list or dictionary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using parse_float as a place to attach arbitrary structured metadata be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading tracker with a TOML string describes books, page targets and review dates. Include one ordinary case, one boundary and one deliberate failure caused by using parse_float as a place to attach arbitrary structured metadata. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For parse_float cannot return a list or dictionary, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

TOML date-time forms map to datetime.datetime, datetime.date or datetime.time according to the value form and offset. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is keeping every temporal value as a string and performing lexical comparisons. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Date and time values become datetime types, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Date and time values become datetime types chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on keeping every temporal value as a string and performing lexical comparisons. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
d=tomllib.loads('day=2026-10-10
start=07:20:00')
print(type(d['day']).__name__,type(d['start']).__name__)

Four purposeful transfer cases

Case 1: science project. Explain the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA website. Transfer the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family planner. Predict the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library catalogue. Contrast the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers keeping every temporal value as a string and performing lexical comparisons.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Date and time values become datetime types, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Date and time values become datetime types?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing keeping every temporal value as a string and performing lexical comparisons be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science project with measurements require Decimal conversion rather than binary floating point. Include one ordinary case, one boundary and one deliberate failure caused by keeping every temporal value as a string and performing lexical comparisons. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Date and time values become datetime types, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A TOML datetime with an offset becomes an aware datetime, while a local datetime has no timezone offset attached. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating a naive local time as a globally comparable instant. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Offset and local datetimes differ, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Offset and local datetimes differ chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating a naive local time as a globally comparable instant. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
d=tomllib.loads('a=2026-10-10T07:20:00+08:00
b=2026-10-10T07:20:00')
print(d['a'].tzinfo,d['b'].tzinfo)

Four purposeful transfer cases

Case 1: family planner. Transfer the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library catalogue. Predict the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Contrast the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Stress-test the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating a naive local time as a globally comparable instant.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Offset and local datetimes differ, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Offset and local datetimes differ?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating a naive local time as a globally comparable instant be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA website with nested tables organise event venue, roles and contact settings. Include one ordinary case, one boundary and one deliberate failure caused by treating a naive local time as a globally comparable instant. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Offset and local datetimes differ, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Syntax that violates the TOML grammar fails rather than producing a partial configuration. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is catching every ValueError and hiding the difference between syntax, callback and application failures. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Invalid TOML raises TOMLDecodeError, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Invalid TOML raises TOMLDecodeError chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on catching every ValueError and hiding the difference between syntax, callback and application failures. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
try: tomllib.loads('x = [1,')
except tomllib.TOMLDecodeError as e: print(type(e).__name__)

Four purposeful transfer cases

Case 1: test laboratory. Predict the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Contrast the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework app. Stress-test the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading tracker. Explain the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers catching every ValueError and hiding the difference between syntax, callback and application failures.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Invalid TOML raises TOMLDecodeError, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Invalid TOML raises TOMLDecodeError?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing catching every ValueError and hiding the difference between syntax, callback and application failures be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with arrays of tables represent several appointments without inventing parallel lists. Include one ordinary case, one boundary and one deliberate failure caused by catching every ValueError and hiding the difference between syntax, callback and application failures. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Invalid TOML raises TOMLDecodeError, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Parsing proves syntax and type conversion, not that required keys, allowed ranges or relationships satisfy a project schema. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is equating a successful parse with a safe deployment configuration. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Valid TOML can still be invalid for the application, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Valid TOML can still be invalid for the application chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on equating a successful parse with a safe deployment configuration. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
d=tomllib.loads('retries=-4')
if d['retries']<0: raise ValueError('retries must be non-negative')

Four purposeful transfer cases

Case 1: homework app. Contrast the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading tracker. Stress-test the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science project. Explain the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA website. Transfer the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers equating a successful parse with a safe deployment configuration.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Valid TOML can still be invalid for the application, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Valid TOML can still be invalid for the application?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing equating a successful parse with a safe deployment configuration be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library catalogue with quoted keys, dotted keys and date values expose conversion boundaries. Include one ordinary case, one boundary and one deliberate failure caused by equating a successful parse with a safe deployment configuration. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Valid TOML can still be invalid for the application, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Official documentation warns that malicious TOML can consume substantial CPU and memory, so input size and source trust belong in the design. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is parsing an unlimited upload merely because TOML is data rather than executable Python. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Untrusted input needs a size boundary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Untrusted input needs a size boundary chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on parsing an unlimited upload merely because TOML is data rather than executable Python. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

from pathlib import Path
p=Path('settings.toml')
if p.stat().st_size>1_000_000: raise ValueError('configuration too large')

Four purposeful transfer cases

Case 1: science project. Stress-test the rule using measurements require Decimal conversion rather than binary floating point. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA website. Explain the rule using nested tables organise event venue, roles and contact settings. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family planner. Transfer the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library catalogue. Predict the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers parsing an unlimited upload merely because TOML is data rather than executable Python.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Untrusted input needs a size boundary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Untrusted input needs a size boundary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing parsing an unlimited upload merely because TOML is data rather than executable Python be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with invalid syntax, wrong file mode, large input and schema mismatches are isolated. Include one ordinary case, one boundary and one deliberate failure caused by parsing an unlimited upload merely because TOML is data rather than executable Python. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Untrusted input needs a size boundary, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The parsed result is independent Python state; changing it neither writes TOML nor preserves comments or formatting. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is modifying data in memory and assuming the configuration file changed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Dictionary mutation does not edit the source file, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Dictionary mutation does not edit the source file chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on modifying data in memory and assuming the configuration file changed. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

import tomllib
d=tomllib.loads('theme="sage"')
d['theme']='blue'
print(d)

Four purposeful transfer cases

Case 1: family planner. Explain the rule using arrays of tables represent several appointments without inventing parallel lists. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library catalogue. Transfer the rule using quoted keys, dotted keys and date values expose conversion boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Predict the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Contrast the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers modifying data in memory and assuming the configuration file changed.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Dictionary mutation does not edit the source file, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Dictionary mutation does not edit the source file?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing modifying data in memory and assuming the configuration file changed be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. Include one ordinary case, one boundary and one deliberate failure caused by modifying data in memory and assuming the configuration file changed. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Dictionary mutation does not edit the source file, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Use tomllib when supported Python needs standards-based TOML reading; choose a writer for emission, a style-preserving library for document editing, and explicit validation for domain rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is choosing a parser before stating whether the job is reading, editing, preserving comments or writing. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Choose tomllib for read-only configuration parsing, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Choose tomllib for read-only configuration parsing chapter on Python tomllib, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on choosing a parser before stating whether the job is reading, editing, preserving comments or writing. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

def read_config(path):
 with open(path,'rb') as f: return tomllib.load(f)

Four purposeful transfer cases

Case 1: test laboratory. Transfer the rule using invalid syntax, wrong file mode, large input and schema mismatches are isolated. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Predict the rule using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework app. Contrast the rule using a project.toml file stores subject names, due dates and feature flags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading tracker. Stress-test the rule using a TOML string describes books, page targets and review dates. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers choosing a parser before stating whether the job is reading, editing, preserving comments or writing.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Choose tomllib for read-only configuration parsing, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python tomllib syntax. For this chapter, useful prompts are: “What did you expect from Choose tomllib for read-only configuration parsing?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing choosing a parser before stating whether the job is reading, editing, preserving comments or writing be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework app with a project.toml file stores subject names, due dates and feature flags. Include one ordinary case, one boundary and one deliberate failure caused by choosing a parser before stating whether the job is reading, editing, preserving comments or writing. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Choose tomllib for read-only configuration parsing, separate the documented Python tomllib mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.

Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.

Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.

1. homework app: model, boundary and recovery

Create a small homework app using a project.toml file stores subject names, due dates and feature flags. Combine “tomllib parses but does not write TOML” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. reading tracker: model, boundary and recovery

Create a small reading tracker using a TOML string describes books, page targets and review dates. Combine “loads reads a Python string” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. science project: model, boundary and recovery

Create a small science project using measurements require Decimal conversion rather than binary floating point. Combine “Arrays of tables become lists of records” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. CCA website: model, boundary and recovery

Create a small CCA website using nested tables organise event venue, roles and contact settings. Combine “Booleans are lowercase TOML tokens” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. family planner: model, boundary and recovery

Create a small family planner using arrays of tables represent several appointments without inventing parallel lists. Combine “parse_float cannot return a list or dictionary” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. library catalogue: model, boundary and recovery

Create a small library catalogue using quoted keys, dotted keys and date values expose conversion boundaries. Combine “Invalid TOML raises TOMLDecodeError” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. test laboratory: model, boundary and recovery

Create a small test laboratory using invalid syntax, wrong file mode, large input and schema mismatches are isolated. Combine “Dictionary mutation does not edit the source file” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. design decision: model, boundary and recovery

Create a small design decision using tomllib is compared with JSON, environment variables, a TOML writer and a style-preserving editor. Combine “Python 3.11 is the module boundary” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.

Should every option or function be memorised?

No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.

What if the result is correct but the explanation is weak?

Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.

Is the shortest solution the best?

Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.

When should official documentation be used?

Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.

How can a parent help without technical expertise?

Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.

How do we test transfer?

Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.

What should be saved after practice?

Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.

Can these exercises replace backups?

No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.

What counts as mastery?

The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

Official and supporting references

• Primary technical documentation for Python tomllib
• eduKatePunggol: How Studying Works

Return to contents