Overview
The records in Part 4 existed while the program was running. If the program stopped, those in-memory records were no longer available to its next run.
A useful application often needs a longer memory. A reading log should still contain yesterday’s sessions. A catalogue should remember which equipment is available. A vocabulary game can remember which translations you found difficult and use that history in the next practice session.
Files let a program store information outside its current execution. File formats let another run, or another program, interpret that information.
The information can stay organized as it was in Part 4. For example, a program can write a list of catalogue records to a file and later load it as another list of records. We need to describe both the file’s contents and the Python values the program should construct from them.
Working with files raises a few questions:
Where is the file? What format does it use? What if the file is missing or its contents are not what we expected? Which parts of the program should know about files at all?
Part 3 provided functions, specifications, tests, and focused exception handlers. Part 4 provided records whose fields we can describe. You will use those tools to read files, check their contents, and process the resulting records.
After working through this part, you should be able to load, validate, process, and save structured data using text files, CSV, and JSON, while keeping file operations separate from calculations.
The structure of this part is as follows:
- Working in a Programming Environment sets up an editor and Python, then practises editing, running, testing, and submitting a local file.
- Text Files and Paths introduces reading, writing, paths, and joining text when producing a file.
- Imports, Libraries, and Documentation introduces reusable source files, imports, guarded entry points, and documented library behavior.
- Tabular Data with CSV connects rows and columns with the records from Part 4.
- Structured Data with JSON stores lists, dictionaries, and other supported values in one structured document.
- Validating External Data distinguishes file failures, malformed formats, and records that violate an application rule.
- Building a Data Pipeline separates loading, validation, calculation, and output, and checks an AI-proposed library claim.
- Files and Games builds Word Practice: read vocabulary, record answers, and calculate statistics across practice rounds.
- Recap and Feedback combines the part in a catalogue-import exercise.
Practice with Small Files
The examples start with disposable text files, then introduce CSV tables and JSON documents. Text, CSV, and JSON use Python’s standard library. The programming exercises supply their own starter code and explain how to run checks.
Chapter 2 sets up your IDE, Python, and the local submission workflow. Download the programming exercises that use data files or multiple source files, work in a separate folder for each exercise, and submit through the IDE plugin or as a ZIP. Each handout identifies the files to edit and gives commands for running the program or its checks. Local files remain between runs, so you can inspect the text, CSV, JSON, and game history that your code writes.
Short runnable examples and value-only validation exercises remain available in the browser. Files created by an ordinary browser example are temporary, so those examples write and read them during the same execution.
Recommended Order of Work
Use the same rhythm as in the earlier parts:
- predict the values or file contents before running an example;
- run it, change one input, and explain what changes;
- complete the nearby tracing and programming exercises;
- test each function with ordinary and empty inputs, then add invalid cases once validation is introduced;
- finish with the game, catalogue importer, and feedback.
After Chapter 6, pause before adding validation. Check that you can explain how a CSV row becomes a typed record, distinguish a JSON string from an open file, and save and load an empty list during one Run. Return to those examples if any step is unclear.
A useful working order is:
Describe the record shape. Read the representation. Validate the result. Only then use it as application data.
Successful parsing is not the same as valid information for your program.