The Python Practicum
A hands-on path from intelligent beginner to independent builder of small, maintainable Python applications.
For beginners with no programming experience. You need only the Practicum app: no Python installation, terminal or account elsewhere.
- How long
- About 14 weeks at 6 to 8 hours a week
- Cost today
- Level 0 free
- The rest
- Early access, by invitation or request
By the end
- Build a small Python application another learner can open, run, test and diagnose without you.
- Make a Python program run predictably, then observe what it actually did.
- Handle files, structured data, HTTP and SQLite while keeping the program's core contract.
- Turn unknown failure into a tested, observable response.
- Package a small application and leave a record that supports its next change.
Python is easy to start and easy to leave in a state that only works on the author's laptop. This practicum closes that gap without asking you to configure a laptop. The app runs Python through Pyodide in an in-app virtual workspace. You will move from expressions to designing a small application with a clear boundary, tests, structured data, persistence, a command-line interface, packaging metadata, and a maintenance record.
The course uses six capability plateaus. You first execute and inspect code, then model data and decisions, design with functions and modules, cross file and network boundaries, make failures visible and recoverable, and finally ship something another learner can open and maintain. Every level ends with work against a labelled fixture or your own permitted data placed in the app workspace. A task you cannot name is a signal to choose a smaller fixture, not to invent a case study.
Cadence
Plan for six to eight hours each week: two hours of lessons and checks, three to five hours on the in-app exercises, and one hour reviewing run history and notes. Each level normally takes two weeks. Save an exported workspace or progress artifact at the end of each exercise so that your maintenance record has evidence rather than recollection.
Proposition
By the final level, you will have a small application another learner can open in the Practicum app, run against a new virtual fixture, test without your presence, and diagnose when it fails. The browser runtime is explicit: Pyodide supports core Python and the standard library, but it does not provide a native virtual environment, subprocesses, raw sockets, OS installation, or direct device filesystem assumptions. Web frameworks, graphical interfaces, machine learning, and infrastructure deployment can be valuable later, but they obscure the core practice this course is designed to establish.
Prerequisites and working agreement
You need only the installed Practicum app and the device running it. You do not need prior programming experience, a Python installation, a terminal, an editor, an external repository, an account, or an internet connection. Use the supplied labelled fixtures or paste a permitted small dataset into the app workspace. Do not paste secrets or personal data into the workspace or exported artifacts.
A lesson is finished when you predict, run, change or break, and explain a program in the app workspace. Reading a page without changing a program does not pass a level.
The levels
- 0Execute and inspectMake a Python program run predictably, then observe what it actually did.Free
- 1Model data and decisionsTurn a working script into a small model whose rules can be named and changed.Locked
- 2Design with functions and modulesCompose a small program whose boundaries can change without rewriting its core.Locked
- 3Cross system boundariesHandle files, structured data, HTTP, and SQLite while preserving the core contract.Locked
- 4Make failures visible and recoverableTurn unknown failure into a tested, observable response that an operator can act on.Locked
- 5
Your build subject
Fixed before Level 0, and everything after it runs against these.
Three things get named before the first lesson and do not change for fourteen weeks.
One: the dataset that is yours. One small, permitted dataset from your own life or work that a small program could genuinely serve: a ledger of dues, a register of members, a log of readings, a folder of monthly returns. It must be data you are allowed to use, it must contain no secrets and no other person's private information, and it must be small enough to paste into the app workspace. The supplied fixtures exist for practice; this dataset exists so that at least one program you build in this course is a program you actually wanted.
Two: the next maintainer. One person, named, who will open your capstone in the Practicum app in Level 5, run it against a fixture they choose, and try to break it. They do not need to know Python well. They need to not be you, because the whole of Level 5 is about what your program looks like without you standing next to it.
Three: the working agreement. Evidence in this course is what the app recorded: run history, exported workspaces, saved fixtures. A result you remember producing but cannot reproduce from the entry file does not count, at any level, and the reason is a rule of practice rather than an inconvenience.
If you genuinely have no dataset of your own, say so in your workspace notes and use the fixtures throughout. That is workable and it costs you the capstone's best property, which is caring whether it survives.
Rules of practice
Seven rules. Break one and the level you are in stops working as designed.
One. Nothing is established by reading. A lesson is finished when you predict, run, change or break, and explain a program. Reading a page without changing a program does not pass anything, and the feeling of having understood a program you did not run is the specific illusion this format exists to remove.
Two. Type the code you are learning. Paste fixtures, paste data, paste your own earlier work. Do not paste the thing the lesson is teaching, because the errors you make typing it are the fastest diagnostic this course has for what you have not yet understood.
Three. Every claim about a program is demonstrated by a run. "It handles the malformed row" is a sentence about run history or it is a hope. If the app cannot show it, it has not been established.
Four. A failure is reproduced before it is explained. From the entry file, on a named fixture, in the app. An explanation constructed from memory of what probably happened is a story, and debugging by story is how a wrong fix gets written on top of a misread failure.
Five. A smaller fixture beats an invented case. When a task cannot be named from your data or the supplied fixtures, shrink the fixture until it can. Nothing in this course runs on an imagined scenario, because a fixture can disagree with you and a scenario cannot.
Six. No secrets in the workspace. No passwords, keys, tokens, account numbers, or personal data about anyone else, in the workspace or in any exported artifact. Exports leave the app; treat them as documents somebody else will read.
Seven. Finished means it survives the handoff. A program is done when another learner can open it, run it against a fixture they chose, test it without you, and diagnose it when it fails. Everything before that is progress.
Assessment
Six artefacts, one per level, marked on reproducibility rather than elegance.
Each level's exercise produces one artefact, and the artefact set is the assessment. The inspection script that runs twice on two fixtures. The rules engine whose decisions are data. The application whose boundary can be replaced. The import that survives a hostile file. The break-diagnose-recover record with the traceback and the smallest repair. And the shipped capstone with its maintenance record, opened and exercised by your named next maintainer.
Every artefact is marked on the same four questions. Does it run from the entry file, on a fixture the marker chooses rather than the one it was built against? Does it fail visibly, reporting the malformed input instead of producing a confident empty result? Is the evidence in the run history rather than in the description? And can the next maintainer see its assumptions without asking you?
Nothing is assessed on how the code looks. Style follows from the design lessons or it does not, and a beautiful program that cannot be re-run from its entry file scores below an ugly one that can.
The capstone carries the most weight, and the part of it people underestimate is the maintenance record: what broke, what it cost, what you changed, and what you would warn the next person about. A program with no recorded failures has not been used.
What is open, and what is not
Level 0 of every programme is free: its lessons, checks and gates need no account, its tools need a free account, and the other levels and the worked exemplars are for early-access members.
Create a free account