Intro to Python
This is the teacher's companion to the student "Intro to Python Workbook." Every section here uses the same color tab as the matching section in the student book, so you can find things by color even faster than by page number.
Teacher: Student:
Term start: Meeting days:
Designed for two 1-hour sessions a week, over 5 weeks (10 sessions total).
How To Use This Edition
Same page design as the student book, different job: this one is for you to read before or during a session, not for the student to write in.
| Box color | What it means here |
|---|---|
| Answer Key | The correct answer to a practice question from the student book. |
| Watch For | A struggle most students hit on this topic, and how to spot it early. |
| Assign This | A concrete task, often with a screenshot to submit. |
| What It Should Look Like | A description of correct output, so you can check work at a glance. |
| History Break | A short, true story about Python to read aloud. Optional, but fun. |
| Pacing Note | How long a section tends to take, and where you can cut or stretch. |
| Teaching Tip | A specific way to explain or demonstrate a tricky idea. |
Every page header names which student pages it covers, like "Covers Student Pages 12-17." Keep both books open side by side during a session.
The 5-Week Course Calendar
Ten sessions, roughly one hour each. Every session lists which student pages to cover and any checkpoint due.
| Session | Topic | Student Pages | Checkpoint |
|---|---|---|---|
| 1 | First Steps: print, input, syntax | 1-8 | - |
| 2 | Variables, Data Map, Strings | 9-17 | - |
| 3 | Numbers, Booleans, None, Review | 18-26 | - |
| 4 | Control Flow, for Loops, range() | 27-33 | - |
| 5 | while Loops, Functions | 34-40 | - |
| 6 | Turtle Setup, Movement, Shapes | 41-46 | Screenshot 1: a shape |
| 7 | Spirals, Flowers, Patterns | 47-48 | Screenshot 2: original art |
| 8 | Randomness, Lists | 49-54 | - |
| 9 | Game State, Game Loop, Debugging | 55-63 | Screenshot 3: mini game |
| 10 | Code Reading, Capstone Kickoff | 64-73 | Capstone due next session |
This calendar is a default, not a contract. If a session runs long, push the leftover pages to the start of the next one - nothing here is time-sensitive except the capstone needing enough sessions left to actually build it. See T4 for how loosely to hold this.
Grading & Assessment Philosophy
This is one-on-one tutoring, not a graded class - so keep assessment light and diagnostic, not evaluative.
For daily practice questions, use a simple 3-tier read on understanding instead of a score: Got it (explain back correctly, unprompted) - Getting there (gets it with a hint) - Needs another look (flip back to the page together next session).
Reserve an actual rubric (see T28) for the capstone project only - that's the one deliverable worth grading formally, since it's the thing a portfolio or parent update would reference.
On screenshot checkpoints
Three checkpoints in this course ask the student to submit a screenshot (Sessions 6, 7, and 9), plus the capstone at the end. Pick one simple channel before Session 1 and stick with it:
- A shared folder (Google Drive, Dropbox) the student saves screenshots into
- Emailing screenshots directly to you after each checkpoint session
- A shared doc where screenshots get pasted inline with the date
A good submission filename: StudentName_Session6_Square.png. It doesn't need to be fancy - it just needs to show the code and the output together (a split screen or two screenshots works fine).
Materials & Setup Checklist
| Item | Notes |
|---|---|
| Python installed | python.org, version 3.10+. Confirm with python3 --version in a terminal. |
| A code editor | IDLE (comes bundled with Python) is enough - no need for anything fancier yet. |
| turtle module | Built into standard Python. If drawings don't open a window, check the install includes tkinter (usually automatic on Windows/Mac). |
| No-install option | replit.com works for typed code, but its turtle support varies - test it yourself before Session 6. |
| Screenshot method | Confirm the student knows their device's screenshot shortcut before Session 6. |
Turtle windows sometimes open behind other windows, or close instantly after the drawing finishes. Fix the second one by ending every turtle program with turtle.done() - it's worth mentioning once up front so it's not a mystery in Session 6.
- [ ] Python runs and can print "Hello, world!"
- [ ] Both books (student + this one) are open side by side
- [ ] Submission method for screenshots is decided
Session 1 Plan
Covers Student Pages 4-8: code/program/syntax vocabulary, print(), input(), and converting input().
~10 min vocabulary (p4) - ~15 min print() (p5-6) - ~15 min input() (p7-8) - remaining time: free practice writing small print/input programs together.
p6 predict: lives = 3 then print(f"Lives left: {lives}") outputs Lives left: 3.
p6 Try It fix: print("score") should be print(score) (no quotes, or the variable's value never shows).
Have the student read code out loud, literally, before running it: "print, open paren, quote, Hello comma world, exclamation point, quote, close paren." Reading punctuation out loud catches missing quotes and parens faster than staring at it.
Common Struggles + History Break
Covers Student Pages 4-8.
Two mistakes appear almost every single Session 1: forgetting quotation marks around text, and mismatched or missing parentheses. Both are worth naming out loud as "the two classic first mistakes" - it takes the sting out of hitting them.
Confusing input()'s return value: students often expect age = input("Age? ") to give a number. Let them hit the error on p8 themselves before showing the int() fix - the error is more memorable than the warning.
"Python isn't named after the snake. Its creator, a Dutch programmer named Guido van Rossum, started writing it in December 1989 as a hobby project to keep busy over the holidays. He was reading scripts from the British comedy show Monty Python's Flying Circus at the time, and wanted a name that was short, a little unusual, and slightly mysterious - so he named his new language after the show. The snake logo came later, once people started making the joke anyway."
Session 2 Plan: Variables & Strings
Covers Student Pages 9-17: variables, naming, the data type map, and the full strings sequence.
Strings is the longest run of pages in the whole book (6 pages). If the session is tight, the data type map (p11) and naming rules (p10) can compress to 5 minutes each - strings deserves the remaining time.
p9 predict: score = 5; score = score + 1; print(score) -> 6.
p10 Try It: valid names are player_name and isAlive. Invalid: 2lives (starts with a digit), high-score (hyphens aren't allowed), for (reserved word).
p13 predict: word = "ha"; laugh = word * 3 -> hahaha.
p14 Try It: word = "GAME", word[1] is "A".
p15 predict: len("ROBOT") -> 5; name[-1] -> "T".
p16 Try It: "play again".replace("play","quit") -> "quit again".
String Roundup Answer Key
Covers Student Page 17 (mini practice) and sets up Session 3.
1. The data type of "42" is a string (str) - it's in quotes.
2. word = "SPACE": word[0] is "S", word[-1] is "E".
3. "go" * 3 prints gogogo.
4. print('It's a bug') breaks because the apostrophe in It's closes the string early. Fix: use double quotes - print("It's a bug").
By this point students often start treating every quoted number as interchangeable with the real number. Ask them directly: "is "5" the number five?" - if they hesitate, revisit p12 before moving to Session 3's numbers content.
Session 3 Plan: Numbers & Booleans
Covers Student Pages 18-26: integers, floats, operators, conversion, Booleans, None, and the review roundup.
p18 predict: lives = 3; lives = lives - 1 -> 2.
p19 predict: x = 5; y = 2.0; x + y -> 7.0 (mixing int and float always gives a float).
p20 predict: 10 // 3 -> 3; 10 % 3 -> 1.
p21 Try It: lives = lives - 1 becomes lives -= 1.
p23 predict: lives = 0; lives == 0 -> True; lives > 0 -> False.
p24 Try It: not False -> True.
p26 #1: "7"=str, 7=int, 7.0=float, True=bool, None=NoneType.
p26 #2 predict: a = 4; b = "4"; a == b -> False (different types are never equal).
p26 #3 bug fix: age = input("Age: ") needs to be age = int(input("Age: ")) before adding 1.
Data-Type Confusions + History Break
Covers Student Pages 18-26.
Floor division (//) versus regular division (/) is genuinely confusing at first - both use a slash. Anchor it to the modulo (%) example on the same page: floor division and modulo are a matched pair (one gives the answer, the other gives the leftover), which is easier to remember than either alone.
For None (p25), don't over-explain it in Session 3 - it's genuinely abstract this early. A one-sentence definition plus "you'll see this again with functions" is enough. It clicks much faster once they hit a function with no return in Session 5.
"The word 'Boolean' - True and False values - comes from George Boole, a mathematician who invented an entire system of logic using just true and false back in 1854, over a hundred years before the first electronic computer existed. Every single if-statement your student writes is built on math from the 1800s."
Session 4 Plan: Control Flow
Covers Student Pages 27-30: if, elif, else, nested conditions, and practice.
p28 predict: with score = 85, only "B" prints - Python stops at the first True branch in an if/elif chain, so the second elif score >= 80 never runs even though it's also true.
p29 Try It: if has_key and enemies_defeated: print("The treasure room opens!").
p30 #1 predict: health = 0 -> prints Game Over.
p30 #2 bug: if score > 10 is missing its colon - fix: if score > 10:.
p30 #3: if coins >= 5: print("Buy a power-up!") else: print("Keep collecting.")
Act out the "player has key" flowchart (p28) physically - stand up, hold an imaginary key, and have the student decide which way to walk. Kinesthetic framing makes the branching stick better than reading it silently.
Loops Answer Key
Covers Student Pages 31-35, split across the end of Session 4 and start of Session 5.
p32 predict: for i in range(3): print(i) -> 0, 1, 2 on three lines.
p33 Try It: range(1, 5) -> 1, 2, 3, 4.
p34 predict: counts down 3, 2, 1.
p35 #1: the loop runs 5 times. #2: the fix is adding count += 1 inside the loop body. #3: for i in range(3): print("Enemy spawned").
Loop Struggles + Session 5 Kickoff
Covers Student Pages 31-35.
Infinite loops are the single most common Session 4/5 event, and it's a good thing - it means they understand while is checking a real condition. Don't rush to fix it for them; ask "what would have to change for this to stop?" first.
range()'s "stops before the last number" rule (same pattern as string indexing) resurfaces as confusion here. If it's still shaky, the number-line diagram on p33 is worth redrawing together from scratch rather than just re-reading it.
If Session 4 finishes through p33, Session 5 opens with while loops (p34) fresh. If it only gets through p31-32, push while loops later and don't compress functions to make up the time - functions deserve their own full runway.
Session 5 Plan: Functions
Covers Student Pages 36-40: what a function is, defining/calling, parameters vs. arguments, and return values.
p38 Try It: in def spawn_enemy(x, y):, the parameters are x and y.
p39 predict: def double(n): return n * 2, then double(4) -> 8.
p40 #1:
def square(n):
return n * n
p40 #2 predict: is_alive(0) -> False; is_alive(3) -> True.
p40 #3 vocabulary: call = actually running the function; parameter = the placeholder name in the definition; argument = the real value passed in; return = sends a value back out; def = the keyword that defines a function.
Function Struggles + History Break
Covers Student Pages 36-40.
The single most common function bug: using print() inside a function instead of return, then being confused why result = my_function() stores None. This is p39's mistake box - if it comes up live, that's the moment to point back to it.
The "function machine" analogy (input in one side, output out the other) works best if you literally draw a box on paper and physically write values flowing through it for two or three example calls before touching the keyboard.
"There's a hidden joke built into Python itself. If you type import this into any Python program and run it, it prints a poem called 'The Zen of Python' - 19 lines of guiding rules for writing good code, like 'Simple is better than complex.' A programmer named Tim Peters wrote it in 1999, and it's still built into every copy of Python today." (Try it together if there's a spare minute - it's a fun way to end the session.)
Session 6 Plan: Turtle Setup & Movement
Covers Student Pages 41-44: importing turtle, movement commands, coordinates, and color/style.
Budget extra time here versus other sessions - environment issues (a window that won't open, a missing turtle.done()) eat time in ways earlier sessions didn't. Test your own setup before the session using T5's checklist.
p42 Try It: t.penup() before moving, t.pendown() after, with the actual move (t.goto() or t.forward()) in between.
p43 Try It: 75 pixels directly below center is the coordinate (0, -75).
If the turtle window opens and then instantly closes, the program finished without a closing turtle.done() or turtle.mainloop() call - Python closed the window because there was nothing left keeping it open.
What It Should Look Like: Shapes
Covers Student Pages 45-46: square, triangle, polygons, and stars.
SQUARE (p45) TRIANGLE (p45) HEXAGON (p46, sides=6) +------+ /\ ___ | | / \ / \ | | / \ \ / +------+ ------ \_/
A correct square or polygon always closes cleanly back to its starting point with no gap or overlap. If the shape doesn't close, the turn angle is wrong - check it against 360 / number_of_sides.
p45 Try It: a hexagon (6 sides) turns 360 / 6 = 60 degrees each step.
p46 Try It: changing sides = 8 to sides = 3 draws a triangle.
A 5-point star (p46) should look like a classic star outline where the lines cross over themselves in the middle - that crossing is expected and correct, not a bug.
Session 7 Plan: Spirals, Flowers & Screenshot 1
Covers Student Pages 47-48: spirals, flowers, and nested-loop patterns.
The spiral (p47) should visibly grow outward in a loose square-ish coil - if it looks identical to a single square, the length += 2 line is missing or not indented inside the loop.
The flower (p47) should look like 10 overlapping circles arranged evenly in a ring, forming a rosette/flower shape. If the circles are scattered instead of overlapping in a ring, the rotation angle (360 / petals) is off.
p47 Try It: to draw 6 petals instead of 10, change both range(10) to range(6) and t.left(36) to t.left(60) (since 360 / 6 = 60). Changing only one of the two produces a broken or overlapping ring.
Have the student pick their favorite drawing from Sessions 6-7 (a shape, a star, a spiral, or a flower) and screenshot both the code and the result. This is the first of three checkpoints - see T4 for the submission method.
Turtle Troubleshooting + History Break
Covers Student Pages 41-48.
Stray diagonal lines across a drawing almost always mean a missing penup() before repositioning. It's the turtle equivalent of a syntax error - visually obvious once you know what to look for.
Nested-loop patterns (p48) are the first time indentation depth actually matters for logic rather than just syntax. If the pattern draws all shapes stacked in one spot instead of rotating around, the rotation line is indented at the wrong level (inside the inner loop instead of after it).
"Turtle graphics didn't start with Python. It was invented in the late 1960s for a teaching language called Logo, built by a researcher named Seymour Papert at MIT. His idea was that kids learn programming best by controlling something that moves in space - and some early classrooms used actual small robot turtles that rolled around on the floor dragging a real pen behind them, drawing on huge sheets of paper. Python's turtle module is a direct descendant of that original idea, over 50 years later."
Session 8 Plan: Randomness
Covers Student Pages 49-50.
p49 predict: random.randint(1, 3) can only ever produce 1, 2, or 3 - both endpoints are included.
p50 Try It: sides = random.randint(3, 10).
Students sometimes expect randint(1, 6) to behave like range(1, 6) and exclude 6. Point directly at the contrast between the two rules on p49 and p33 - it's a deliberate, useful comparison, not just trivia.
"Computers can't actually generate true randomness - they just follow instructions, and instructions aren't random. What Python's random module really does is run a mathematical formula that produces a long, unpredictable-looking sequence of numbers. It's called 'pseudo-random' - close enough to random for games and art, but technically a very complicated pattern."
Lists Answer Key
Covers Student Pages 51-54.
p52 predict: items = ["sword", "shield"]; items[0] = "axe" -> ['axe', 'shield'].
p53 Try It: enemies.append("dragon").
p54 predict: scores = [70, 85, 90] summed in a loop -> 245.
p54 Try It: for score in high_scores: print(score).
Index errors on lists feel like a fresh bug to students even though it's the exact same rule as string indexing from Session 2. Naming that connection out loud ("remember index 0 from strings? same rule here") saves re-teaching from scratch.
Session 9 Plan: Game State & Loop
Covers Student Pages 55-58: game state, the game loop, and game vocabulary.
Run the input -> update -> check rules -> output -> repeat cycle (p56) as a live "you be the computer" exercise: you call out inputs, the student has to say out loud what the state variables become and what gets printed, one full cycle at a time.
These four pages are conceptual and vocabulary-heavy with no code to run - it can feel slow after the hands-on turtle sessions. Keep it brisk; the real payoff lands on the next page when it all shows up together in actual code.
Don't let vocabulary (p57-58) eat more than 15 minutes total - it's meant to be a quick reference, not a memorization drill. The tracing exercise on p59 is where the time should go.
Mini Game Trace + Screenshot 3
Covers Student Page 59.
Full trace for target = 4, guesses 2 then 4:
- Guess 1 (
2): not equal to 4 -> printsTry again.->attemptsbecomes1 - Loop check:
attempts < 3 and not wonis still True -> loop continues - Guess 2 (
4): equal to target ->won = True, printsYou won in 2 tries! - Loop check:
not wonis now False -> loop ends, final "out of tries" message is skipped
Have the student run the dice or guessing game (from p59, or their own variation) to a full finish and screenshot the terminal output showing the whole playthrough, win or lose.
Debugging: Coaching + History Break
Covers Student Pages 60-63.
These pages have no fixed answers - the skill is the process (p61's Bug Detective steps), not a specific fix. When the student hits a real bug, resist fixing it yourself. Ask the questions from p61 out loud instead: "what did you expect? what actually happened?" Let them find the line.
Watch for the student changing multiple things at once when a bug appears - it's the single habit most worth correcting this session. Physically stop them and ask "what's the one thing you're changing right now?"
"The word 'bug' for a computer error is older than you'd think, and one story about it is even literally true. In 1947, a team led by computer scientist Grace Hopper found their computer, the Harvard Mark II, malfunctioning - and traced it to an actual moth stuck in one of its mechanical relays. They taped the moth into their logbook with the note 'first actual case of bug being found,' and the logbook still exists in a museum today."
Code Reading Answer Key
Covers Student Pages 64-65.
p64 trace: starting x=5, y=2. After x = x + y: x=7, y=2. After y = x - y: x=7, y=5. Final print(x, y) -> 7 5.
p65 #1: total sums 1 through 5 -> 15.
p65 #2: mystery(7) -> 7 % 2 is 1, not 0, so it returns "odd".
p65 #3: the loop runs 3 times; the first printed line is 0 a.
If the trace table on p64 is still shaky, have the student narrate each line as "the right side happens first, then gets stored" - the same rule from p9's variable box, just applied twice in a row.
Session 10 Plan: Capstone Kickoff
Covers Student Pages 66-67: the Game Design Blueprint and Planning Worksheet.
Your main job this session is scoping, not building. A student's first instinct is almost always to plan something too big. Push toward the smallest version of their idea that still has a clear win and lose condition - it can always grow later.
A win or lose condition that isn't actually checkable in code ("win by having fun") is the most common blueprint gap. Ask directly: "what line of Python would check if they won?" If they can't answer, the condition needs to be more concrete.
By the end of this session, the student should leave with a filled-out blueprint and worksheet, and have started the smallest working piece (usually: one shape on screen, or one working input prompt). The full build happens as homework before the next check-in.
Capstone Rubric + Final Submission
| Criteria | Points | What to look for |
|---|---|---|
| Runs without crashing | 2 | Executes start to finish on a normal input. |
| Uses a loop | 2 | A for or while doing real repeated work. |
| Uses a function | 2 | At least one def, called at least once. |
| Uses a conditional | 2 | At least one meaningful if. |
| Clear win/lose condition | 2 | The player can tell the game ended, and why. |
| Visual element (bonus) | +1 | Any use of turtle. |
| Readable code | 2 | Sensible variable names, at least one comment. |
Have the student submit their .py file plus a screenshot (or short screen recording) of it running. This is the final checkpoint of the course - treat it like a small showcase, not just a grade.
Student: Total: / 13
Wrap-Up + What's Next
Covers Student Pages 68-73: the reference section and capstone checklist.
Pages 68-72 in the student book are pure reference (symbols, vocabulary, the "when do I use this" chart, analogies) - there's nothing to key, but they're excellent for a quick verbal quiz: point at a symbol or term and ask the student to explain it cold.
"Everything your student just learned - variables, loops, functions - are the same basic ideas running some of the biggest software in the world. Python powers huge parts of Instagram, helps NASA analyze data from space missions, runs Netflix's recommendation system, and is the language most modern AI tools are built in. The turtle drawings and dice games use the exact same core ideas, just at a much smaller scale."
If continuing past 5 weeks, natural next directions: pygame for real interactive games with graphics and key input, classes/objects for more organized code, or more advanced turtle projects combining everything learned here into bigger art pieces.