Use python3 as the canonical command name course-wide (#104) (#105)
CI / check (push) Successful in 7s
Sync course wiki / sync-wiki (push) Successful in 4s

This commit was merged in pull request #105.
This commit is contained in:
2026-06-23 20:25:05 -04:00
parent 7f439212ac
commit 95e5911957
102 changed files with 380 additions and 378 deletions
+4 -4
View File
@@ -78,7 +78,7 @@ Almost every CI configuration, on every forge, is the same four moves:
4. **Run the checks**: lint, then test. Any check that exits non-zero fails the whole run.
That last point is the load-bearing one. CI's entire enforcement mechanism is the **exit code**.
Every tool you'd run in a terminal returns 0 for success and non-zero for failure. `python -m
Every tool you'd run in a terminal returns 0 for success and non-zero for failure. `python3 -m
unittest` exits non-zero if a test fails. `ruff check` exits non-zero if it finds a lint problem. CI runs your
commands and watches those exit codes; one failure turns the run red. You're not learning a new
testing system; you're wiring the tools you already have to a trigger.
@@ -154,7 +154,7 @@ When CI goes red, the skill is triage, and it's fast once you know the shape:
3. **Read that step's log.** It's the same output the tool prints in your terminal: a failing
`unittest` assertion, a `ruff` finding with a file and line number. CI didn't invent a new error
format; it's showing you the command's own output.
4. **Reproduce it locally.** The same command from the failed step (`python -m unittest` or
4. **Reproduce it locally.** The same command from the failed step (`python3 -m unittest` or
`ruff check .`) fails the same way on your own machine, because CI ran exactly that command. That
reproducibility is the point: fix locally, confirm green locally, push again.
@@ -254,7 +254,7 @@ your machine first.
that CI is nothing more than these same two commands is what makes the rest of the module click.
```bash
python -m unittest # should report all tests passing
python3 -m unittest # should report all tests passing
ruff check . # should report no issues (or fix what it flags)
```
@@ -325,7 +325,7 @@ and watch CI stop it.
`git restore` (Module 12). What the agent runs looks like:
```bash
python -m unittest # fails locally too: same command, same failure
python3 -m unittest # fails locally too: same command, same failure
git revert --no-edit HEAD # new commit that undoes "Simplify pending()" (Module 12)
git push # CI re-runs on the fixed code and goes green again
```
@@ -15,11 +15,11 @@ This is the running example for **Module 1** (where you feel the copy-paste prob
## Run it
```bash
python cli.py add "read module 1"
python cli.py add "set up my editor"
python cli.py list
python cli.py done 0
python cli.py list
python3 cli.py add "read module 1"
python3 cli.py add "set up my editor"
python3 cli.py list
python3 cli.py done 0
python3 cli.py list
```
Requires Python 3.10+ (it uses `list[Task]` style type hints). No third-party packages.
@@ -1,8 +1,8 @@
"""Tiny command-line front end for the demo task app.
Run it:
python cli.py add "write the lesson"
python cli.py list
python3 cli.py add "write the lesson"
python3 cli.py list
State is kept in tasks.json next to this file. It's intentionally minimal; the point of this app
is to be a realistic-but-small thing you change with an AI, not a product.
@@ -31,7 +31,7 @@ def save(tlist: TaskList) -> None:
def main(argv: list[str]) -> int:
tlist = load()
if not argv:
print("usage: python cli.py [add <title> | list | done <index> | count | delete <index>]")
print("usage: python3 cli.py [add <title> | list | done <index> | count | delete <index>]")
return 1
command = argv[0]
@@ -2,7 +2,7 @@
Reproduced here so this module's lab is self-contained: if you already wrote tests in Module 13,
use those instead. Standard-library `unittest`, exactly like Module 13, nothing to install.
Run locally with `python -m unittest` from the project folder. CI runs exactly this.
Run locally with `python3 -m unittest` from the project folder. CI runs exactly this.
"""
import unittest