Skip to content

Projects

~15 min to read, several weeks to finish the set

In short

These are ten projects, arranged from beginner to intermediate. Each one has a goal, a checklist of requirements you can test, the skills it uses, and a stretch idea for when you finish. Do them in order. Projects 1 to 3 come from the Python course's capstones, which have full acceptance checks; the rest are described here only. A project is done when every checkbox is ticked and your tests pass, not when it looks finished.

How to grade your own work

Each project has a level from 1 to 3. Level 1 needs a single file and no external libraries. Level 2 adds files, tests, or a second module. Level 3 adds a design choice you have to justify in writing. Write a short README in your project folder that says how to run it, what the tests cover, and one thing you would change next time.

The projects

Project 1: Command-line expense tracker (level 1)

Goal. A program you run in the terminal that records expenses, saves them to a file, and totals them.

Requirements.

  • [ ] The program reads commands in a loop until quit.
  • [ ] add AMOUNT CATEGORY NOTE stores an expense and prints its id.
  • [ ] list, total, and delete ID work as the capstone describes.
  • [ ] Expenses are saved to a file after each change and loaded on start.
  • [ ] Bad input prints a message, and the program does not crash.

Skills used. Input and output, loops, lists and dictionaries, functions, files, exceptions. See capstone 1.

Stretch idea. Add a budget CATEGORY LIMIT command that warns when a total goes over the limit.

Project 2: Text adventure with classes (level 1 to 2)

Goal. A small game with rooms, items, and a locked door, where the world is described by data.

Requirements.

  • [ ] The program defines Room, Item, and Player classes, and a Key class that inherits from Item.
  • [ ] go, look, take, and inventory commands work.
  • [ ] A locked door opens only when the player carries the right item.
  • [ ] Adding a room means adding data, not new logic.
  • [ ] The player can reach the goal room in a single run.

Skills used. Classes, inheritance, dictionaries, and a command loop. See capstone 2 and Part 7 on objects.

Stretch idea. Save and load the game state to a JSON file.

Project 3: REST notes API (level 2)

Goal. A web service that stores notes and lets a client create, read, update, and delete them over HTTP.

Requirements.

  • [ ] A health route returns a success status.
  • [ ] Create, list, read, update, and delete routes return the status codes the capstone lists.
  • [ ] Invalid input is rejected with a client error, not a crash.
  • [ ] Tests call each route and check the response body.
  • [ ] Storage is in one class, so the routes do not depend on how notes are stored.

Skills used. HTTP, JSON, validation, classes, and automated tests. See capstone 3 and Part 8 on the backend. The capstone uses FastAPI; its documentation is at https://fastapi.tiangolo.com/.

Stretch idea. Add a route that filters notes by a word in the title.

Project 4: File search tool (level 1 to 2)

Goal. A command-line tool, similar in purpose to grep, that searches text files in a folder for a word.

Requirements.

  • [ ] The tool takes a folder, a word, and an optional --ignore-case flag.
  • [ ] It prints the file name, line number, and matching line for each match.
  • [ ] It skips files that are not text, and it reports them without stopping.
  • [ ] It exits with status 0 when there is a match and 1 when there is none.
  • [ ] It works on a folder with nested subfolders.

Skills used. Reading files, walking folders, command-line arguments, and exit codes. Useful references: argparse, pathlib, and os.

Stretch idea. Add a count of matches per file and a summary line at the end.

Project 5: A small package with tests (level 2)

Goal. A library of unit conversions, such as length and mass, organised as a package with tests and a README.

Requirements.

  • [ ] The conversions live in at least two modules, and one module imports from the other.
  • [ ] Each public function has a docstring and a test.
  • [ ] The tests cover one ordinary case, one edge case, and one invalid input per function.
  • [ ] Tests run with a single command and pass.
  • [ ] The README shows two example calls and their output.

Skills used. Modules and imports, functions, exceptions, and unit testing. See modules and imports and the unittest documentation.

Stretch idea. Write a second set of tests that checks conversions round-trip, such as converting metres to feet and back.

Project 6: Web server log analyser (level 2)

Goal. A program that reads a web server access log and reports request counts, status codes, and the most requested paths.

Requirements.

  • [ ] You create a sample log file yourself, with at least 200 lines in a simple text format that you describe in the README.
  • [ ] The report lists the number of requests per status code.
  • [ ] It lists the five most requested paths.
  • [ ] Malformed lines are counted and skipped, not allowed to crash the run.
  • [ ] The output is the same every time you run it on the same file.

Skills used. Dictionaries, counting, sorting, parsing text, and handling errors. The collections documentation describes counters, and the dictionaries lesson covers the basics.

Stretch idea. Read gzip-compressed logs with the gzip module.

Project 7: A key-value store on disk (level 2 to 3)

Goal. A small storage class that keeps key-value pairs in a file, so they survive a restart.

Requirements.

  • [ ] The class has set, get, and delete methods.
  • [ ] Each change is appended to a log file, and the store rebuilds its state from that file on start.
  • [ ] A compact method rewrites the file so it holds only the latest value for each key.
  • [ ] A test stops the process in the middle of writes and checks the store still opens.
  • [ ] A short written note explains what happens if the process stops during a write.

Skills used. File handling, classes, testing, and reasoning about failure. See files and exceptions.

Stretch idea. Add a checksum to each record, and skip records whose checksum does not match when the store starts.

Project 8: Bank statement reconciler (level 2 to 3)

Goal. A program that matches the rows of a bank statement against a ledger you keep, and lists the rows that do not match.

Requirements.

  • [ ] The program reads two CSV files, one for the statement and one for the ledger.
  • [ ] Amounts are handled as exact decimal values, not floating-point numbers.
  • [ ] A row matches when the date, amount, and reference agree.
  • [ ] The report lists unmatched rows from each file, with a total for each side.
  • [ ] Tests use a small pair of files you write, and include one row with a date difference.

Skills used. CSV parsing, dates, exact decimal arithmetic, and writing a report. See the csv module and the decimal module.

Stretch idea. Allow a date window of up to two days and show which rows matched because of it.

Project 9: A database-backed library catalogue (level 2 to 3)

Goal. A catalogue of books stored in an SQLite database, with a script that measures how an index changes query speed.

Requirements.

  • [ ] The database has a table with at least four columns and a primary key.
  • [ ] The program inserts at least 100,000 generated rows.
  • [ ] A query by author is timed before and after an index is added.
  • [ ] The query plan is printed, so you can see whether the index is used.
  • [ ] A short note records the timings and says how you measured them.

Skills used. SQL, schema design, indexes, timing code, and reading query plans. See SQLite CRUD in the backend part and the sqlite3 documentation, or the SQLite documentation.

Stretch idea. Repeat the exercise on PostgreSQL and compare the query plans.

Project 10: A small classifier with honest evaluation (level 3)

Goal. A program that trains a simple classifier on a small public dataset and reports how well it does on data it has not seen.

Requirements.

  • [ ] You name the dataset, where you got it, and its license in the README.
  • [ ] The data is split into a training part and a test part before any training.
  • [ ] The program reports accuracy on the test part, and compares it with a baseline that always predicts the most common label.
  • [ ] You do not tune the model on the test part.
  • [ ] A written note says what the result does not show, such as a small or unbalanced dataset.

Skills used. Data handling, probability and counting from discrete mathematics and probability, functions, and careful evaluation. Use any language library you choose, and write down why.

Stretch idea. Compare two simple models on the same split, and explain the difference in one paragraph.

Notes

  • None of these projects is required by any course described on this site. They are practice.
  • Each project takes longer than it looks. As a rough guide, plan one to three weeks per project at one or two sessions a week, and stop when the checklist is complete. These figures are estimates, not measurements.
  • If a project is too hard, drop the stretch idea and finish the checklist. A finished level 1 project is worth more than an unfinished level 3 one.

Sources