Milestone map
Milestone map
5 milestones
Write Pythonic code, not just Python
1–2 weeks. The Pythonic rewrite takes an afternoon. The CSV program takes 2–3 days the first time — file I/O always surprises.
Rewrite one of your Learn to Code programs using Python idioms. Use list comprehensions, f-strings, enumerate(), zip() and the with statement. The new version must be shorter and clearer. Then write a program that reads a CSV file and processes each row. It writes a summary to a new file. Use only the standard library, no pandas.
Proof required
Share a Gist or repo with the before and after versions side by side. Share the CSV program with a sample input file and its output. Write 150 words on what makes Python idiomatic. Say what you removed, and why the shorter version is better, not just shorter.
What gets checked
- The rewrite swaps a loop, string joining or manual file close for an idiom.
- The CSV program reads a file you made. It produces a real summary, not printed rows.
- The reflection names a specific readability or safety gain, not 'it's cleaner'.
Common mistakes
- Comprehensions everywhere, even where a loop is clearer. Pythonic means readable.
- Downloading a CSV instead of making one. The point is to understand the format.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Run the CSV program on an unexpected file: an extra column, a missing field. Does it cope?
- Ask them to read one comprehension as a sentence. If they can't, they copied it.
- If the reflection only says 'fewer lines', ask what bug the shorter version prevents.
You'll sign in first, then come straight back here.
Work with APIs and external libraries
1–2 weeks. Finding the right API takes longer than using it. Budget a day just for API selection.
Install two libraries with pip. Use requests to call a free public API you choose. Turn the JSON into useful output. Then pick a second PyPI library that solves a problem you have. Don't use one suggested here. Write a program combining both to do something neither does alone.
Proof required
Share the code in a GitHub repo. The README lists both libraries, why you chose each, and sample output. Write 150 words on how you chose the second library. Say what you read: the PyPI page, docs or a tutorial. Say what would have made choosing easier.
What gets checked
- The second library is your own pick. Not numpy, pandas, matplotlib, flask or django.
- The combined program does something real, not just printing both results together.
- The reflection names the docs or sources you used, not 'I googled it'.
Common mistakes
- Using a tutorial's API because it came up first. Pick a topic you care about.
- Installing a library without reading its README first.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask them to switch the API call to another resource. Can they change and re-parse it?
- Ask what happens if the API is down. No error handling means it's incomplete.
- If the second library is an obvious one, ask why. Ask what else they considered.
You'll sign in first, then come straight back here.
Write tests for your own code
1–2 weeks. Writing the first 3 tests takes a day. Writing the next 5 — the edge cases — takes longer because you have to think about what could go wrong.
Write a pytest test suite for your Milestone 2 program. You need at least 8 tests. Cover the happy path and edge cases: empty input, maximum input, unexpected types. Include at least one test that fails before you fix the bug it catches. Run the tests, then break your code on purpose and watch them fail.
Proof required
Share the repository with the test file. Share a screenshot of pytest with every test passing. Share a second one after you broke a function, with at least one test FAILED. Write 150 words on one bug your tests caught that you'd have missed.
What gets checked
- At least 8 separate test_ functions, not 8 asserts in one function.
- At least one test covers an edge case you hadn't handled. It failed before your fix.
- The reflection names the input that caused the bug and what the code did wrong.
Common mistakes
- Only testing what you know works. Tests that only pass are documentation.
- One function with 8 asserts. When it fails, you can't tell which one broke.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Count test_ functions. Fewer than 8 means incomplete, whatever the assert count.
- Ask them to add a test for an uncovered edge case. Can they find one in 2 minutes?
- If the caught bug was already known, the test didn't catch it. The test should have found it.
You'll sign in first, then come straight back here.
Build a data pipeline from files
2–3 weeks. The CLI takes half a day. The reproducibility requirement takes longer than expected — running it twice and comparing output hashes is the test.
Automate a multi-step data task you actually need. Read data from several CSV, JSON or text files. Clean it: remove duplicates, handle missing values, reformat dates or strings. Write the result to a new file in a different format. Running it twice on the same input must give identical output. Add a command-line interface so it runs on new files without code changes.
Proof required
Share the repository with a sample dataset you made. The README explains what it does and how to run it on other inputs. Record a 3-minute video running it on two input files. Write 200 words on one data quality problem and how you chose to handle it.
What gets checked
- It's reproducible, the README says so, and nothing is random or time-dependent.
- The interface uses argparse or sys.argv, not hardcoded file paths.
- The reflection names a specific problem, like dates in two formats. It explains your choice.
Common mistakes
- Using pandas when you don't need it. If data fits in memory, the standard library is enough.
- Hardcoded file paths. If nobody else can run it, it's a script, not a pipeline.
Resources
Foundationstart here
Masteryfor the dedicated
What a verifier looks for
- Run it twice on the sample input and compare outputs. Not identical means not reproducible.
- Give it a file path that doesn't exist. A helpful message beats a traceback.
- Ask how they decided to handle the data problem. Deliberate choice or a guess?
You'll sign in first, then come straight back here.
Publish a Python package on PyPI
2–3 weeks. The packaging setup takes a full day the first time. Publishing to PyPI is 30 minutes once packaging is done. Finding a real user is the hard part.
Package your most useful functions from Milestones 1–4 as a library anyone can install. It needs a clear name. Its README says what it does and how to install it. It needs at least 5 passing tests, a version number and a license file. Publish it on PyPI so anyone can pip install it. Get at least one stranger to install and use it.
Proof required
Share the PyPI page URL. Show someone else installed it, through an issue, message or comment. Anonymised is fine. Write 200 words on what you packaged and why others need it. Say what you'd do differently building a package from scratch.
What gets checked
- It installs with pip in a fresh virtual environment and imports without errors.
- Someone else installed it: a genuine user, not a friend doing a favour.
- The reflection names a structural choice, like API design or naming, not 'better docs'.
Common mistakes
- Packaging something the standard library already does. Nobody will use it.
- No tests. A published library without tests is a liability.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- In a fresh environment, pip install it and print its __version__. Failure means it isn't properly published.
- Ask them to demo it solving its problem in 2 minutes without the README.
- Read the PyPI page as a stranger. Is the purpose clear in two sentences?
You'll sign in first, then come straight back here.
Part of