Use python3 as the canonical command name course-wide (#104)
CI / check (pull_request) Successful in 7s
CI / check (pull_request) Successful in 7s
Most current systems (default Debian/Ubuntu, recent macOS) install Python only as `python3`, with no bare `python` on PATH, so learners who copied `python cli.py ...` into their host shell hit "command not found". Convert host-shell `python <cmd>` -> `python3 <cmd>` across module/lab READMEs, lab `.py` docstrings & usage strings, blog posts, lab prompt and instruction files, the M04 verify.sh message, and the M10/M24 lab patches. Module 01's convention note (and its blog/02 mirror) is rewritten so `python3` is canonical and `python` is the documented fallback. Stop-lines respected: Docker image tags (`python:3.12-slim`), `.venv/.../python` and `...\.venv\Scripts\python.exe` paths, the M20 `"command": "python"` teaching example and surrounding venv prose, container-internal invocations (M16/M18 Dockerfiles, M16 README `docker run` examples), and CI-workflow `run:` steps fed by `actions/setup-python` / `image: python:3.12` are left as `python` on purpose. pip was left out of scope: most occurrences are prose or CI/container-internal, and `pip3` does not fix the PEP 668 externally-managed-environment refusal that the course already addresses with venvs. The M01 note is worded to stay consistent with bare `pip` (use whichever pip pairs with your Python). Build (tools/build_wiki.py) and tools/check.sh both pass. Closes #104 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GAEzanEoGJT5o1VizQar47
This commit is contained in:
@@ -87,7 +87,7 @@ This is the distinction to lock in, because the two are siblings and easy to con
|
||||
| Analogy | The standing house rules posted on the wall | A labeled recipe card you pull out when you cook that dish |
|
||||
|
||||
They're complementary. The instructions file is the right home for facts true *all the time* ("tests
|
||||
run with `python -m unittest`"). A skill is the right home for a procedure you run *sometimes* ("here
|
||||
run with `python3 -m unittest`"). A skill is the right home for a procedure you run *sometimes* ("here
|
||||
is exactly how we add a command"). Module 5 even told you this was coming: start with the always-on
|
||||
file; graduate a procedure into a skill when it earns its own page.
|
||||
|
||||
@@ -147,7 +147,7 @@ On paper this is just "write a runbook." The AI-specific twist is what changes t
|
||||
|
||||
- **The AI will execute the playbook, not just read it.** A runbook for a human is a reminder; a skill
|
||||
for an agent is something it *performs*. The precision pays off immediately: vague step, vague
|
||||
result; imperative step ("run `python -m unittest`; do not claim success until it's green"), reliable
|
||||
result; imperative step ("run `python3 -m unittest`; do not claim success until it's green"), reliable
|
||||
result.
|
||||
- **The AI is confidently incomplete without one.** Asked to "add a command," it'll happily stop at
|
||||
the code and skip the test, the changelog, the clean commit, and sound finished doing it. The skill
|
||||
@@ -222,8 +222,8 @@ seen, producing all four parts without you listing the steps.
|
||||
5. Watch it perform the procedure. A correctly-followed skill will, without you saying any of it:
|
||||
- add `clear()` to `tasks.py` and wire a `clear` branch into `cli.py` (logic in the right file);
|
||||
- add a real test to `test_tasks.py` that asserts the list is empty afterward (not just "no crash");
|
||||
- run `python -m unittest` and show it green;
|
||||
- smoke-test `python cli.py clear` and show the output;
|
||||
- run `python3 -m unittest` and show it green;
|
||||
- smoke-test `python3 cli.py clear` and show the output;
|
||||
- add a `CHANGELOG.md` line;
|
||||
- stage code + test + changelog into one commit, **without** `tasks.json`.
|
||||
|
||||
@@ -232,8 +232,8 @@ seen, producing all four parts without you listing the steps.
|
||||
6. Don't take the AI's word for it. Check against the skill's own done-criteria:
|
||||
|
||||
```bash
|
||||
python -m unittest # green, and a clear-related test is present
|
||||
python cli.py add "x" && python cli.py clear && python cli.py list # -> (no tasks yet)
|
||||
python3 -m unittest # green, and a clear-related test is present
|
||||
python3 cli.py add "x" && python3 cli.py clear && python3 cli.py list # -> (no tasks yet)
|
||||
git show --stat HEAD # one commit: tasks.py, cli.py, test_tasks.py, CHANGELOG.md; no tasks.json
|
||||
```
|
||||
|
||||
@@ -318,6 +318,6 @@ time:
|
||||
that the example skill format stays generic (when-to-use / inputs / steps / done-criteria).
|
||||
- [ ] **Dependency chain intact.** Confirm Module 20 (MCP) and Module 22 (securing servers/skills) are
|
||||
still numbered as referenced, and that nothing here leans on a tool introduced after Module 20.
|
||||
- [ ] **Lab still runs.** `python -m unittest` is green in `lab/tasks-app/`, and the `clear`-command
|
||||
- [ ] **Lab still runs.** `python3 -m unittest` is green in `lab/tasks-app/`, and the `clear`-command
|
||||
walkthrough still matches the starter files (`add`/`list`/`done`/`count`, `test_tasks.py`,
|
||||
`CHANGELOG.md`).
|
||||
|
||||
Reference in New Issue
Block a user