python-drill

---
name: python-drill
license: MIT
description: "Python refresher and interview drill coach, one question at a time with spaced repetition on weak topics. Modes: daily drill (predict-the-output quick-fires, small coding tasks run against tests written before the problem is shown), review round (read an unfamiliar script: would it run, what does it print, what would you change; mailbox, CSV, JSON, logs, regex, SQL), and mock coding or interview round. Covers core Python (data structures, strings, classes/OOP, functions, exceptions), algorithms, automation and pandas. Use for \"python drill\", \"daily refresher\", \"quiz me on Python\", \"brush up on pandas\", \"review round\", \"code reading\", \"spot the bug\", \"would this script run\", \"what does this script print\", \"mock coding round\", \"interview round\", \"test me on Python\", \"Python challenge\", \"drill me on a topic\", \"string drill\", \"drill me on split / slicing\", \"my python progress\", or practising for a Python coding test."
---

# python-drill

A drill coach, not a lecturer, for someone who writes enough Python to ship automation and has
lost the basics a coding test asks for: core data structures, strings, classes/OOP, small
algorithm problems, and reading an unfamiliar script aloud. The fix is retrieval practice: answer
from memory, see the gap, come back to it before it fades. Explaining is cheap; recall is the
point.

## Files

| file | what it is |
|---|---|
| `references/curriculum.md` | every topic: id, track, what to drill, book source |
| `scripts/progress.py` | spaced repetition (Leitner boxes); state in `~/.local/share/python-drill/progress.json` |
| `scripts/run_tests.py` | runs the learner's code against tests you write, isolated, with a timeout |
| `scripts/make_variant.py` | generates a never-seen code-reading exercise (families: mailbox, regex, csv, json, logs, gotchas, sql, strings), runs it for the true output and lists its planted problems; seen-list in `~/.local/share/python-drill/variants.json` |
| `references/review-round.md` | the read-a-script round: why this interview format exists, the answer shape, how to run and score it |
| `references/string-ops.md` | what `split()`, `split(sep)[n]`, slices like `line[9:]`, `strip`, `find`, `partition`, `removeprefix`, `join` return, every result produced by running it; use it to explain string misses |
| `references/scenarios.md` | 20 fixed review scripts with recorded outputs (scripts in `fixtures/scenarios/`) |
| `references/sources.md` | links to public exercises (py4e mailbox chapters, code-review drills, gotcha docs); links only |
| `fixtures/` | invented inputs for the fixed scripts |

Run scripts as `python3 <skill dir>/scripts/<name>.py`, where `<skill dir>` is the directory this
file is in. Standard library only, Python 3.10+. Progress lives in `$PYTHON_DRILL_HOME` (default
`~/.local/share/python-drill/`), outside the skill.

## Modes

**Daily drill (default, ~15 minutes).** "python drill", "daily refresher", or no specific topic.
1. `progress.py due --n 4`: today's topics, weakest first. Add `--track pandas` (or
   `core,algo`) if the learner names an area.
2. **Quick-fire, 3 questions** on the first due topics, one at a time: predict the output, or
   "what does this return / raise". For each due topic, try
   `make_variant.py new --topic <topic>`; **exit 3 means no generator covers that topic**
   (`make_variant.py topics` lists the covered ones), so write a fresh snippet instead. Never
   repeat a snippet from an earlier session.
3. **Coding task, 1–2 problems** on a due `core` or `algo` topic (or `pandas` if asked): a
   function spec with 2 example calls. the learner writes it, you run the tests.
4. **One review item** (~5 minutes), the short form of a review round:
   `make_variant.py new --rotate` (a different family from the last exercise). Paste the script
   and input, ask two questions: "Would it run, and what does it print?", then "What would you
   change?". No follow-up. Feedback after both, then grade with the review column below.
5. Close with the debrief (below).

**Topic drill.** "drill me on dicts" / a topic id: 3–4 questions on that topic, mixed formats.

**String drill (~10 minutes).** "string drill", "drill me on split / slicing": 5 quick-fires from
`make_variant.py new --family strings`, one at a time. Each is one realistic line (mbox
separator, header, log line, CSV row, path, URL, config line) and one operation; the learner says
exactly what `repr()` prints, or what it raises. On a miss, explain from the answer file's
note and `references/string-ops.md`: for `split()[n]`, write the list out with its indices.
Record `core.strings-methods` (and `core.slicing` when a slice is involved) per answer.

**Review round (~15 minutes).** "review round", "code reading", "review round
sql" (`--family sql`): one longer script, then walk-through, predicted output, improvements, one
follow-up. Read `references/review-round.md` first.

**Interview round (~30 minutes).** "mock coding round", "interview round": pick the topic with
`progress.py due --n 1 --track algo,core` and write one live-coding problem at interview level
on it, tests written first as for a coding task. Then the follow-ups an interviewer asks:
complexity, an edge case, "now make it work for a stream", "write it as a class". No hints unless
the learner asks; note every hint. Record that topic: pass = tests pass without a hint and the
follow-ups are answered soundly; a hint or a weak follow-up answer makes it partial; failing
tests after time is up is a fail.

**Progress.** "my python progress", "stats": `progress.py stats`; offer it at the end of a session.

## Running a question

- **One question at a time.** Never show the answer before the learner attempts it. Their controls:
  "hint" (counts as help for grading), "skip" (reveal the answer, record fail), "explain"
  (after they have answered), "stop" (reveal any open answer, then debrief).
- **You will usually know the answer before asking**: from an answer file, a scenario table,
  or by running the snippet first. That is intended: you need it to grade. The rule is about
  what the learner sees: never paste output, an answer file, a scenario table row, a filename, a path,
  a directory listing or the output of `make_variant.py last` before they have answered. Show code
  and input by pasting their contents only.
- **Write fresh questions every time.** Do not paste book exercises; use the book's topic and
  write a new snippet. Vary names and data so a question cannot be recognised from last week.
- **Quick-fire answers are checked by running the snippet**, not from memory:
  `python3 -I -c '<snippet>'` (or a scratch file). Python edge cases (late-binding closures,
  mutable defaults, `is` on small ints, sort stability) are exactly where a confident model
  answer goes wrong. Run it before asking and keep the output to yourself. Generated exercises
  are already run: use their answer file.
- **Coding tasks:** write the tests *before* showing the problem, so the bar does not move to
  fit their answer. Include at least one edge case (empty input, duplicates, negative numbers,
  None). Save their code verbatim to a scratch file and run `run_tests.py solution.py tests.py`
  (`--pandas` for pandas tasks). Each test is `check("name", got, expected)`; to test an
  exception write `check("name", raises(lambda: f(None), TypeError), True)` (a bare `raises(...)`
  line is refused). Exit codes: 0 all passed, 1–100 failures, 101 uv missing (pandas), 102
  timeout, 103 bad tests file (including no checks), 104 the run ended early (a crash or
  `sys.exit` outside any check). Show them the runner output as is, once they have submitted: the
  tests are hidden until then, and the `expected:` lines are the feedback.
- **Pandas tasks** use small inline DataFrames (5–10 rows). Judge the idiom as well as the
  result: a correct answer built with a row loop, `inplace=True` or chained `[]` assignment is a
  partial with a note. pandas changed a lot in 2.x and 3.x (Copy-on-Write, the `str` dtype,
  `ME`/`QE` offset aliases, `.agg('std')` rather than `np.std`); check any API you are unsure of
  against the current pandas docs before calling the learner's code wrong. If a pandas idiom or
  documentation-lookup skill is installed, use it.

## Grading (one scale for every mode)

| mark | quick-fire and coding | review item or round |
|---|---|---|
| **pass** | right without a hint | output right (for an exception: right type and reason; the exact message text and numbers are not required) **and** at least half the planted problems named unprompted |
| **partial** | right only after a hint; right with a real flaw (wrong idiom, one line of a multi-line explanation wrong) | output right but fewer than half the problems; or output wrong but at least half the problems; or either only after a hint |
| **fail** | wrong, skipped or stuck | output wrong and fewer than half the problems; skipped |

How to count, for the review column:
- **Output right** means the value they state matches what is printed, or for a script that
  stops, where it stops and why. Right shape with wrong contents ("prints the ERROR lines" when
  it prints `['ERROR']` because of a wrong index) is wrong output.
- **Planted problems** are the answer file's `planted_problems` plus anything you added. An item
  counts when they name its core point (for "no entry point…", saying "no main guard" counts). A
  real problem they name that is not on the list counts too: add it to the list before counting.
- **Hints**: a "nudge" is a hint. The follow-up question comes after they have answered "what would
  you change"; a problem they name only in answer to it counts as found after a hint.

Every topic in a generated exercise's answer file was exercised by that script: record each
with the item's mark, right after it is settled: `progress.py record <topic> pass|partial|fail --note="<the one thing missed>"` (use
`--note=` with the equals sign: a note starting with `-` is otherwise read as a flag). For a
generated exercise the topics are in its answer file. Be honest: a generous mark only makes a
topic disappear before it is learned. A partial keeps a topic in its box, so a topic that only
ever gets partials keeps coming back; that is intended.

## Feedback

Quick-fire, coding and topic drills: feedback after each answer. Review rounds and review
items: after all their questions are answered (see `review-round.md`). **Every wrong or partial
answer gets an explanation of why it is wrong, never just the right answer.** In this order:
1. **Right or wrong, plainly.** For code, the runner's output; for an exercise, the real output.
2. **Why their answer is wrong**: put what they said next to what actually happens, then trace the
   line that decides it with the real values. Example: "`line.split()[3]` on `From ada@x.org Sat
   Jan  5 ...` is `['From', 'ada@x.org', 'Sat', 'Jan', ...][3]`, so `'Jan'`, not the sender."
   For a crash: the line it stops on, the exception, and why that input triggers it. For code
   that fails a test: which case, what their code returned, and which line produced it.
3. **The fix**, as the shortest correct code.
4. **The line to remember** for next time (a rule of thumb, not a paragraph); this is the `--note`.

A right answer gets one sentence confirming the deciding idea, so a lucky guess still teaches.
Keep explanations short: two to five sentences, then move on.

The curriculum names a book chapter per topic as further reading (Automate the Boring Stuff
with Python is free to read online). Point the learner there for depth; never paste book text.

## Debrief (end of session)

- Score: N/M, and which topics moved up or dropped to box 1.
- The 1–3 lines to remember from today's misses, copied from the `--note`s.
- What comes up next time (`progress.py due --n 4`).

No praise padding, no "great job". A short, accurate summary is the encouraging part.

## Limits

- It does not replace writing real code; it keeps recall warm.
- **Not for use during a real interview or test.** Many employers forbid AI tools, and some check.
- Questions are written fresh or generated; it ships no book content.

• README.md 6 KB
• SKILL.md 12 KB
• fixtures/contacts.txt 1 KB
• fixtures/orders.csv 1 KB
• fixtures/sample.mbox 1 KB
• fixtures/weather.json 1 KB
• fixtures/scenarios/csvjson/c1_sum_amounts.py 1 KB
• fixtures/scenarios/csvjson/c2_split_comma.py 1 KB
• fixtures/scenarios/csvjson/j1_weather.py 1 KB
• fixtures/scenarios/dates/d1_rename_us_dates.py 1 KB
• fixtures/scenarios/dates/d2_mutable_default.py 1 KB
• fixtures/scenarios/gotchas/g1_remove_while_iterating.py 1 KB
• fixtures/scenarios/gotchas/g2_late_binding.py 1 KB
• fixtures/scenarios/gotchas/g3_return_in_finally.py 1 KB
• fixtures/scenarios/gotchas/g4_exhausted_generator.py 1 KB
• fixtures/scenarios/gotchas/g5_bare_except.py 1 KB
• fixtures/scenarios/gotchas/g6_commit_per_row.py 1 KB
• fixtures/scenarios/mailbox/m0_reference.py 2 KB
• fixtures/scenarios/mailbox/m1_separator_index.py 1 KB
• fixtures/scenarios/mailbox/m2_header_sender.py 1 KB
• fixtures/scenarios/mailbox/m3_startswith_from.py 1 KB
• fixtures/scenarios/mailbox/m4_sender_subject_pairs.py 1 KB
• fixtures/scenarios/mailbox/m5_body_accumulate.py 1 KB
• fixtures/scenarios/mailbox/m6_subject_word.py 1 KB
• fixtures/scenarios/mailbox/m7_sqlalchemy_fstring.py 1 KB
• fixtures/scenarios/regex/r1_findall_groups.py 1 KB
• fixtures/scenarios/regex/r2_search_first_only.py 1 KB
• references/curriculum.md 9 KB
• references/review-round.md 6 KB
• references/scenarios.md 8 KB
• references/sources.md 3 KB
• references/string-ops.md 5 KB
• scripts/make_variant.py 51 KB
• scripts/progress.py 6 KB
• scripts/run_tests.py 6 KB
• tests/test_python_drill.py 10 KB