Teacher & librarian resources
Intro to Python Programming
Facilitation guide for workshops, libraries, and classrooms
This curriculum is written for the adult leading the session: library staff running a coding club, a teacher adding an enrichment unit, a workshop volunteer, or a parent guiding one student. No programming background is required - each lesson tells you what to say and what to watch for.
Before you start
- Who it is for
- Grades 3-6, no experience needed
- Length
- 8 lessons, 50-60 minutes each
What students need
- A computer, laptop, or Chromebook with a modern web browser (Chrome, Edge, Safari, or Firefox).
- An internet connection to open the lesson pages and load the in-browser Python playground.
- Optional: paper for planning code, and headphones if working through lessons individually.
Running a session in a library or classroom
- Open the week's lesson page and read The idea and the vocabulary together as a group.
- Demonstrate the starter code once on a shared screen, running it so everyone sees the output.
- Give students time to run the starter code themselves and try the mini challenge.
- Circulate while students work, using the suggested questions to check understanding.
- Close with the debugging challenge and the reflection question as a whole-group discussion.
- Plan for 50 to 60 minutes. If time is short, the mini challenge or reflection can be sent home.
Supporting students who have never coded
- Reassure students that error messages are a normal part of coding, not a sign of failure.
- Encourage typing changes by hand rather than copying, so the syntax has a chance to sink in.
- Pair a first-time coder with a partner, or seat them where you can check in often.
- Read code out loud in plain English ("print shows this text on the screen") to build vocabulary.
- Let students who finish early try the extension challenge instead of waiting for the group.
Lesson-by-lesson facilitation guide
One section per week. Each is written so you can lead it without a coding background.
Week 1
What is Python?
Lesson goal
Students understand that code is a set of ordered instructions and write their first program using print().
Materials needed
- Computers or tablets with a web browser
- The Week 1 lesson page open to the playground
- Optional: a whiteboard for writing example print() lines together
What to explain
- A program is a list of instructions the computer follows in order, from top to bottom.
- print() shows on the screen exactly what is inside the quotation marks.
- Every print() needs parentheses, and text needs quotation marks around it.
Common student mistakes
- Leaving off the quotation marks around text, such as print(Hello) instead of print("Hello").
- Missing or mismatched parentheses.
- Expecting the computer to guess meaning - it prints exactly what is typed.
Questions to ask
- What do you think this line will print before we run it?
- What happens if we swap the order of two print lines?
- Why did the computer show an error on this line?
Optional extension
Add a blank line to your card by writing print() with nothing inside the parentheses. Use it to split your card into two neat sections.
If computers are limited
Play "robot instructions": one student gives another step-by-step spoken commands to draw a simple shape. Missing or out-of-order steps show how literally computers follow instructions.
Week 2
Variables and Data Types
Lesson goal
Students store information in variables and use them to build sentences with print().
Materials needed
- Computers with a browser and the Week 2 lesson page
- Optional: labeled envelopes or sticky notes to model variables as boxes
What to explain
- A variable is a labeled box that stores a value you can reuse.
- Text values (strings) go in quotes; number values do not.
- An f-string lets you drop a variable inside a sentence using curly braces.
Common student mistakes
- Putting quotes around a variable name inside an f-string, which prints the name instead of its value.
- Adding quotes to numbers that should stay numeric.
- Naming variables inconsistently, with spaces or stray capital letters.
Questions to ask
- What is stored in this variable right now?
- Which of these values are text, and which are numbers?
- How could we describe a different person without rewriting every line?
Optional extension
Add a number variable called high_score and print one sentence that uses both name and high_score, like: Alex's best score is 25.
If computers are limited
Hand out labeled envelopes (name, age, favorite animal) and have students put a slip of paper inside each. Reading the envelopes aloud models how a variable holds and reuses a value.
Week 3
Input and Interaction
Lesson goal
Students use input() to collect answers and respond to them, turning a program into a two-way conversation.
Materials needed
- Computers with a browser and the Week 3 lesson page
- Optional: a printed script for the offline chatbot role-play
What to explain
- input() asks a question and pauses until the user types an answer and presses Enter.
- The answer can be stored in a variable and used later in the program.
- input() always gives back text.
Common student mistakes
- Forgetting the quotation marks around the prompt text inside input().
- Expecting the program to keep going before the user presses Enter.
- Trying to do math on an answer without converting it to a number (that comes next week).
Questions to ask
- Where does the program stop and wait for the user?
- How is this different from last week's program that only printed?
- What should the program say back using the answer?
Optional extension
Ask for the player's name and their favorite game, then print one sentence that uses both, like: Alex is ready to play soccer!
If computers are limited
Role-play a chatbot: one student is the program and may respond only using a printed script plus the answers the user gives. It shows how input feeds the response.
Week 4
Conditionals
Lesson goal
Students use if, elif, and else so the program does different things depending on the answer.
Materials needed
- Computers with a browser and the Week 4 lesson page
- Optional: a whiteboard or floor space to draw or walk a decision tree
What to explain
- A condition is a question that is either true or false.
- Code indented under an if runs only when its condition is true.
- elif and else handle the other cases.
- Comparing values uses two equals signs (==); one equals sign (=) stores a value.
Common student mistakes
- Using = instead of == when comparing two values.
- Forgetting to indent the code under if, elif, or else.
- Forgetting that text comparisons are case-sensitive ("Earth" is not "earth").
Questions to ask
- What condition are we checking here?
- Which branch will run if the answer is this?
- Why did the program choose that response?
Optional extension
Turn it into a personality quiz: ask a would-you-rather question and print a different result for each choice using if, elif, and else.
If computers are limited
Run a decision tree on the floor with tape or signs: students answer a yes/no question and walk to the matching branch. It makes if/elif/else visible.
Week 5
Loops
Lesson goal
Students use a while loop to repeat actions and give the player more than one try.
Materials needed
- Computers with a browser and the Week 5 lesson page
- Optional: paper for the offline higher/lower guessing game
What to explain
- A loop repeats code so you do not have to rewrite it.
- A while loop keeps going as long as its condition stays true.
- Something inside the loop must eventually make the condition false, or it runs forever.
- int() turns typed text into a number so it can be compared.
Common student mistakes
- Writing a loop whose condition never becomes false (an infinite loop).
- Forgetting int(), so a typed "7" never equals the number 7 and the loop never ends.
- Forgetting the colon at the end of the while line.
Questions to ask
- What has to happen for this loop to stop?
- What changes each time through the loop?
- Why might this loop run forever, and how would we fix it?
Optional extension
Change the range to 1 to 100 and give the player only 7 tries. Stop the loop and print Out of guesses! if they run out.
If computers are limited
Play a paper guessing game: one student thinks of a number 1 to 10 while another guesses and is told "higher" or "lower." Counting the guesses models the loop and the comparison.
Week 6
Functions
Lesson goal
Students define and call functions to reuse code and keep programs organized.
Materials needed
- Computers with a browser and the Week 6 lesson page
- Optional: a printed recipe card to model a reusable function
What to explain
- A function is a reusable recipe: define it once, then call it whenever you need it.
- def creates a function; writing its name with parentheses calls it.
- A parameter is an input the function accepts, listed inside its parentheses.
- Defining a function does not run it - calling it does.
Common student mistakes
- Defining a function but never calling it.
- Calling a function without the argument it requires.
- Forgetting the colon after the def line, or not indenting the function body.
Questions to ask
- What does this function do, and what does it need to do its job?
- Where is the function defined, and where is it called?
- How would this program look if we could not use functions?
Optional extension
Write a function next_level(level) that prints a line like You reached level 5! using the number you pass in, then call it with a few different levels.
If computers are limited
Write a simple recipe (for example, folding a paper airplane) as named steps, then "call" it twice with different inputs such as different paper colors. It shows define-once, reuse-many.
Week 7
Lists and Randomness
Lesson goal
Students store many values in a list and use random.choice() to make programs unpredictable.
Materials needed
- Computers with a browser and the Week 7 lesson page
- Optional: a bag or bowl with slips of paper to draw from at random
What to explain
- A list holds many values in one variable, written inside square brackets.
- import random brings in the random toolbox.
- random.choice() picks one item from a list at random, so each run can be different.
Common student mistakes
- Forgetting import random at the top ("random is not defined").
- Missing commas or brackets when writing a list.
- Expecting the same output every run and thinking the randomness is a bug.
Questions to ask
- How many possible outcomes could this program produce?
- What makes each run different?
- What could we add to the list to change the game?
Optional extension
Ask the player's name with input() at the start, then use it in the random story so the adventure feels like it is about them.
If computers are limited
Put several outcome slips in a bag and have students draw one to build a random story aloud. It models a list plus a random choice.
Week 8
Final Game Builder
Lesson goal
Students plan and build their own mini game, combining everything from the program.
Materials needed
- Computers with a browser and the Week 8 lesson page
- Paper for planning the game before coding
What to explain
- Real programs combine many small ideas that were learned separately.
- Start with a short written plan, then add one feature at a time and test as you go.
- A small game that works beats an ambitious one that does not run.
Common student mistakes
- Trying to write the whole game at once instead of in small, tested steps.
- Reintroducing earlier bugs (missing colons, = versus ==, forgetting int()).
- Skipping the plan and getting stuck.
Questions to ask
- What is the smallest version of your game that could run?
- Which week's idea will you use here?
- You hit an error - what does the message tell you?
Optional extension
Redesign the skeleton into your own game: a trivia round, a story with choices, or a high-score chaser. Use at least one list, one function, and one loop.
If computers are limited
Have students design their game on paper first: the goal, what the player types, and what the program says back. Students without a computer can still complete and present the design.