Python programming, senior
Twelve weeks from first line to a working command-line application, using real tools, version control and tests.
- Grades
- 9–12
- Ages
- 14–18
- Length
- 12weeks
- Sessions a week
- 2
- Each session
- 90min
- Class size
- 15max
What this course is
The core Senior Tech Cadets course, and the one most students start with. It assumes nothing and moves quickly, and it treats a fifteen-year-old as somebody capable of using the same editor, terminal and version control that a working developer uses.
The syllabus is built around a single running theme: a program becomes useful when it can handle data it did not write itself. Students move from arithmetic to lists and dictionaries to files to an API, and each step is motivated by a limitation the previous step ran into.
By the end, every student has a command-line application of their own design on a public GitHub repository, with a README, error handling and a small suite of tests. That artefact is the point of the course as much as the syntax is.
Week by week
Every week ends with something that did not exist at the start of it. That is what is listed under “ends with”.
- Week 01
Environment, terminal and first commit
Python and VS Code installed, the terminal explained rather than avoided, and Git configured. Students learn what a repository is before they have anything to put in one.
Ends with: A first program pushed to the student's own GitHub repository.
- Week 02
Types, input and control flow
Strings, numbers, booleans, conversion, if-elif-else, and the errors that come from confusing a number with its text.
Ends with: A unit converter that validates what the user typed.
- Week 03
Loops and iteration patterns
For and while, break and continue, accumulating a total, and the off-by-one error as a phenomenon rather than a mistake.
Ends with: A program that summarises a list of numbers several ways.
- Week 04
Functions and scope
Parameters, return values, default arguments, local versus global, and why a function that both prints and returns is usually a design mistake.
Ends with: A module of reusable functions imported into a second file.
- Week 05
Lists, dictionaries and choosing between them
The two workhorse structures, nesting them, and the first honest look at why lookup cost differs.
Ends with: A contact book held in a dictionary, with add, search and delete.
- Week 06
Files and CSV
Reading and writing files, context managers, and parsing a CSV of a few thousand rows.
Ends with: A report generated from a real CSV dataset, written out to a new file.
- Week 07
Errors and defensive code
Exceptions, try and except, raising deliberately, and validating input at the edge of a program instead of everywhere inside it.
Ends with: The week 6 program hardened against missing files and malformed rows.
- Week 08
Modules, packages and pip
Virtual environments, installing a package, and reading somebody else's documentation to work out how to call it.
Ends with: A project with a virtual environment and a requirements file.
- Week 09
Talking to an API
HTTP requests, JSON, status codes, API keys and why a key never goes into a commit.
Ends with: A program that fetches live data and presents it readably.
- Week 10
Objects
Classes, instances, attributes and methods, introduced at the point where passing dictionaries around has become unwieldy.
Ends with: The contact book rewritten around a class.
- Week 11
Testing and Git in earnest
Writing tests with pytest, what makes a test worth having, plus branches, commits with useful messages, and pull requests.
Ends with: A test suite that passes, merged through a pull request.
- Week 12
Final project and code review
A command-line application of the student's own design, finished, documented, and walked through in front of the group.
Ends with: A public repository with a README, tests and a working application.
What they will be able to do
- Write and structure a multi-file Python program
- Use Git and GitHub as a matter of routine
- Read documentation and integrate an unfamiliar library or API
- Write tests, handle errors deliberately, and review somebody else's code
What they build
- A validated unit converter
- A CSV data report generated from a real dataset
- A live-data program built against a public API
- A documented, tested command-line application of the student's own design