Introduction

Welcome to the From Scratch Programming Class — a free class for kids and teens, and the textbook that goes with it.

This book is a record of everything we cover in class, written so you can read it on your own. Every chapter matches one class session. If you went to class, the chapter is your reference for what we did. If you missed class, the chapter is how you catch up.

How to use this book

Read it whichever way works best for you.

• Reading after class. Skim the chapter to remind yourself what we covered. The exercises you did in class are written out here so you can do them again or finish what you didn't get to.
• Reading because you missed class. Look for the If you missed this session section near the end of the chapter. It's a shorter, self-paced version that gets you ready for next week. Should take about twenty or thirty minutes.
• Reading ahead. Some students like to read the next chapter before class. That's fine, even encouraged. Reading ahead doesn't excuse you from doing the in-class exercises — that's where the thinking happens — but coming in with questions is great.

How chapters are organized

Every chapter is built the same way:

1. What we're learning today. A short paragraph or two on the point of the session.
2. You'll need to remember from last time. A few bullet points from previous sessions you'll lean on today.
3. Part A. A new concept, with a guided exercise.
4. Part B. Practice or a small project that uses Part A.
5. Wrap-up. A few questions to think about.
6. If you missed this session. The catch-up version.
7. Stretch and extension ideas. Optional extras.
8. What's next. One sentence on where we go from here.

If class gets cut short, Part A always stands on its own. You'll miss the practice in Part B, but you'll have everything you need to keep going next week.

A note about asking for help

Two rules in this class:

• Ask your buddy first, then your instructor. It cuts down on people waiting and makes you better at explaining what you're stuck on, which is half of figuring it out.
• You're done when you can explain how it works. Not when the code runs. Not when it looks right. When you can walk someone else through what your program does, line by line, you're done. Until then, you're not.

A note about the curriculum

This book covers about 150 hours of class — anywhere from one to two years, depending on how often your class meets. It starts with Scratch and ends with small web applications you can run in a browser. You don't need to know anything to start. You don't need a computer at home — most classes provide one for you to keep.

If you're reading this years after taking the class and trying to remember how to do something, the search bar at the top of the site is your friend. The book is here for you whenever you need it.

Now turn the page. Or click the next arrow. Either way, let's go.

For students

A quick guide to how the class and this book work.

Two rules

These two rules cover most of what you need to know about how class works:

• Ask your buddy first, then your instructor. Every student has a buddy, assigned by your instructor. When you get stuck, ask your buddy before raising your hand. If you and your buddy are both stuck, then it's your instructor's turn.
• You're done when you can explain how it works. An exercise isn't finished just because the code runs. It's finished when you can walk someone else through what your code does. If you can't explain it, you're not done yet.

Each chapter has two parts

In class, we usually do Part A in the first half and Part B in the second half. If class gets cut short for any reason, Part A always stands on its own — you won't be missing anything required.

Part B usually has tiered goals:

• Base — what everyone should aim to finish.
• Stretch — try it if you have time.
• Extension — for if you want to keep going past stretch.

You're done when you finish the base goal. Stretch and extension are bonus, never required.

You can stop when you're done

If you're someone who can't stop until something is "perfect" — you have permission to stop. The base target is the actual finish line. Your instructor will tell you to stop sometimes. Listen to him.

If you miss a session

Find the chapter for the session you missed. Skip to the section called If you missed this session. It's a shorter version that gets you ready for next week. About twenty or thirty minutes of work on your own.

Don't worry about it. Missing sessions happens to everyone.

When you get stuck

Stuck is normal. Programming is mostly being stuck and then getting unstuck. The Getting unstuck appendix has a checklist that helps. Work through it in order before asking for help. Half the time you'll fix it yourself.

Words you don't know

When you hit a word you've never seen before — sprite, sequence, conditional, variable, whatever — check the Glossary. It explains words in plain language. The glossary grows as the curriculum moves forward, so words from later sessions get added when those sessions start.

Reading ahead

If you want to read the next chapter before class, go for it. Just don't skip the in-class exercises when we get there — the exercises are where the actual learning happens.

Working on your own at home

Anything you do in class, you can also do at home. The Installing on your own computer appendix tells you how to set up Scratch (and later, Python) on any computer you have access to.

Personal projects — things you build on your own time, not for class — are the highest-value thing you can do as a programmer. If you have an idea, build it. Bring it to class and show your instructor. We love seeing what you build.

A few more things to know

• You can't break the computer by clicking buttons. Software is hard to break by accident. Click everything. Try things. That's how you learn.
• Save your work. Especially big projects. Files have a way of vanishing when you didn't mean them to.
• Ask "why" sometimes. When something works and you're not sure why, ask. The "why" is usually more important than the "how."
• Be a good buddy. You'll often be the one helping someone else get unstuck. The best way to help is the same as the best way to get unstuck: ask them what they want to happen, and what they've already tried. Don't just take their keyboard.

Where to start

If you're brand new, start at Session 1: Welcome & the peanut butter problem. Or pick the chapter for whichever session is happening this week. The textbook is yours — use it however helps.

Phase 1 — Scratch

Welcome to the first phase of the From Scratch Programming Class. This is where you start.

What this phase is

Phase 1 teaches you the ideas of programming using a tool called Scratch. You don't type code — you snap colorful blocks together. The blocks make a cat (and other characters) do things on a screen.

That probably sounds like a kid's toy. It is, sort of. It's also how millions of people learn to program for the first time, because Scratch lets you focus on the thinking part of programming without getting tangled up in typing, spelling, and weird symbols.

By the end of Phase 1, you'll have built a complete, playable game of your own design. Then in Phase 2 we'll switch to a real programming language (Python) — and you'll discover that almost everything you learned in Scratch carries straight over.

What you'll learn

The nine sessions of Phase 1 teach the core ideas every programmer uses, every day, for their entire career:

Every one of those concepts shows up again in Python (Phase 2-4), in desktop apps (Phase 5), in 2D games (Phase 6), in web pages (Phase 7), and in web applications (Phase 8). What changes is the language and the tools. The ideas are the same.

What you'll build

By the end of Session 7, you'll have built a small arcade-style game called Apples and Rocks: a cat that catches falling apples for points and dodges falling rocks (one rock and game over). Combines every idea from Sessions 2-6.

By the end of Session 9, you'll have built a second game of your own design and shown it to the class. Could be a maze, a pet care game, a clicker, a story, a quiz — whatever you imagine, using everything you've learned.

What you'll need

If you're in the class at Old Zion Hill, the answer is: nothing. The class provides a computer with Scratch already installed, and you keep it.

If you're following along on your own, you need:

• A computer (any computer — Windows, Mac, Linux, even a school Chromebook works).
• Either an internet connection (so you can use Scratch at scratch.mit.edu) or Scratch Desktop installed on your machine. The Installing on your own computer appendix has details.

How sessions work

Each session is one class meeting, about 90 to 120 minutes long. Every session has the same shape:

• Part A introduces a new idea with a guided exercise. If class gets cut short, Part A always stands on its own.
• Part B is open-ended practice or a project that uses Part A. Sometimes tiered into base / stretch / extension goals.
• Wrap-up is a few minutes of sharing what you did.

Each session also has an If you missed this session section near the end of the chapter — about 20 to 30 minutes of self-paced work that gets you ready for next week if you couldn't make it.

Where to start

Session 1: Welcome & the peanut butter problem is where it begins. If you went to class, that's the chapter that matches what we did. If you're starting from this textbook on your own, that's where to read first too.

When you're stuck, the Getting unstuck appendix has a checklist that helps. The Glossary explains the vocabulary words we use in class.

Welcome. Let's go.

Session 1: Welcome & the peanut butter problem

Phase 1 — Scratch · Session 1 of 9

What we're learning today

Today is your first day of programming class. We're going to talk about what programming actually is, play a game that will probably make your instructor look ridiculous, and open up the program we'll use for the next couple of months. By the end, you'll know why being precise matters more than being fast, and you'll have clicked around inside Scratch enough to feel like it's not a stranger.

You'll need to remember from last time

Nothing! This is your first session. Welcome.

Part A: What is programming, really?

Let's start with a question: what is a computer?

You probably said something like "a machine that does stuff," or "a thing with a screen." Those are true. But here's a harder question: how does a computer do stuff? Who tells it what to do?

Here's the answer we're going to spend a whole year unpacking:

A computer does exactly what someone tells it to do. Nothing more, nothing less. It can't guess what you mean. It only knows what you say.

That sounds simple. It isn't. We're going to prove it right now.

The peanut butter and jelly problem

Your instructor is going to pretend to be a computer. You are going to be the programmers. Your job: tell the computer (your instructor) how to make a peanut butter and jelly sandwich. The computer will do exactly what you say.

You'll go around the room, each person giving one instruction at a time. Your instructor will follow each instruction as literally as possible. If you say "put the peanut butter on the bread," he might just set the unopened jar on the unopened bag of bread. Because that's what you said.

Here's what you'll discover:

• The computer doesn't know what "open" means unless you say how.
• The computer doesn't know what to spread peanut butter with unless you say what.
• The computer doesn't know that bread comes in slices, or that the slices need to be next to each other, or that the jelly goes on the bread and not on the table.

You will probably end up laughing a lot. That's fine. The laughing is the lesson.

What this means

A computer is like the instructor-as-computer, but worse. At least your instructor knows what bread is. A real computer doesn't. It doesn't know what anything is until you tell it.

Here's the cool part:

When you learn to give instructions that precise, you can make the computer do anything.

Games. Apps. Websites. Tools that make your life easier. Things nobody has ever made before. That's what we're learning to do this year.

Talk about it

Before we move on, talk through these questions as a group:

• What were some things we forgot to tell the computer that turned out to matter?
• What kinds of things did the computer assume? Was it ever right?
• If you had to write down all the steps to make a sandwich so a real computer could do it, how many steps do you think it would take?

(The real answer to that last one: way more than you'd guess. Hundreds. Maybe more.)

Part B: Meet Scratch

Now let's meet the tool we'll use for the next couple of months. It's called Scratch, and it's a programming language designed for people who are just starting out. You build programs by snapping blocks together — like LEGO, but the blocks make things happen on your screen.

Open Scratch on your computer. Look for the orange cat icon on your desktop, or find it in the Applications menu.

A tour of the screen

Scratch divides the screen into a few areas. Don't worry about memorizing this — you'll get used to it fast.

• The stage (top right). This is where things happen. The orange-and-white cat you see is called a sprite — a character on the stage.
• The blocks panel (left side). These are instructions you can give to sprites. They're grouped by color. Blue blocks make things move. Purple blocks change how things look. There are lots of others. We'll learn them as we go.
• The script area (middle). This is where you build your program by snapping blocks together.
• The sprite list (bottom right). All the sprites in your project. Right now, just the cat.
• The green flag and red stop sign (top of the stage). Green flag runs your program. Red stop sign halts it.

Try this together

Let's get the cat to do something on purpose.

1. Drag a move 10 steps block (it's blue, near the top of the blocks panel) into the script area in the middle.
2. Click on the block. The cat moves a little.
3. Click on it again. It moves more.
4. Drag a turn 15 degrees block onto the bottom of the first one. They should snap together.
5. Click on the stack. The cat moves and turns.
6. Click on it twenty more times.

Your cat should now be in a weird place doing weird things. That's correct.

Now go explore

For the rest of class, just play. Try any blocks you want. Make the cat do silly things. Try to make it walk off the screen. Try to make it spin in circles. Try to make it say something (hint: look at the purple blocks).

There are no wrong answers right now. You're getting comfortable. That's the whole goal.

If you find a block that looks interesting and you don't know what it does — try it. That's how you'll learn most of what you learn this year.

Wrap-up

Before we leave, we'll go around and share:

• What was the silliest thing you got the cat to do?
• Did anything happen that you didn't expect?
• Did you find any blocks that looked interesting but you didn't try?

You did great today. Next week, we'll start telling the cat what to do on purpose.

If you missed this session

You missed your instructor trying to spread peanut butter with a comb. There's no replacement for that, sorry. But here's what you need to know:

1. Programming is telling a computer exactly what to do. Computers can't guess. They do what you say, even when what you say is wrong.
2. Open Scratch on your computer. It's already installed — look for the orange cat icon on your desktop or in the Applications menu.
3. Drag a few blocks from the left panel into the middle area, snap them together, and click them. Try the blue ones first (they make things move). Mess around for fifteen or twenty minutes.

When you come next week, you'll be ready to keep up. If anything's confusing, ask your buddy at the start of class.

Stretch and extension ideas

If you finished early or want to keep going at home:

• Find a say block (purple) and make the cat say something.
• Add a second sprite from the sprite library (look for the cat-with-plus icon at the bottom right).
• Try to make the cat walk in a square shape. Hint: how many turns? How many degrees each turn?

What's next

Next week we'll learn how to make sprites do things in order — and what happens when the order is wrong.

Session 2: Sequences and the stage

Phase 1 — Scratch · Session 2 of 9

What we're learning today

Last week you played around in Scratch and got the cat to do silly things. Today we'll do the same kinds of things, but on purpose. You'll learn how to start a program with the green flag, how to make a sprite do several things in a row, and what happens when the order of those things is wrong. By the end you'll have built a tiny scripted scene — your first real program.

You'll need to remember from last time

• Computers do exactly what you say. No guessing. (The peanut butter rule.)
• Scratch is on your computer and you know how to open it.
• Blocks snap together like LEGO in the script area.
• The green flag runs your program. The red stop sign halts it.

Part A: Telling the cat what to do, in order

Open Scratch and start a new project. (File menu → New, or just restart Scratch.)

What "in order" means

Last week you clicked individual blocks and watched the cat react. That works, but it's not really programming yet — you were the one deciding when each block ran. A real program does several things in order, all on its own, after you start it once.

The way you start a program in Scratch is the green flag. You've already seen it — it's the green triangle at the top of the stage. We need a block that says "when the green flag is clicked, do this." That block lives in the Events category (yellow blocks).

Drag this one out:

when [green flag] clicked

It looks a little different from other blocks — it has a curved top and no notch above it, because nothing snaps on top of it. It's a starting block. Things snap below it.

Build a sequence

Snap these blocks together, in this order, under the green flag:

when [green flag] clicked
move 50 steps
wait 1 seconds
turn ↻ 90 degrees
move 50 steps

The wait 1 seconds block is in the Control category (orange). The others you've already met.

Now click the green flag at the top of the stage.

The cat moves 50 steps, pauses for one second, turns 90 degrees, and moves 50 more steps. Every time. In that order. Click the green flag again and it does the same thing again from wherever it ended up.

That's a sequence — a list of instructions that runs from top to bottom. It's the most basic kind of program.

Now break it

Programmers learn fastest by breaking things on purpose, so let's break this on purpose.

Drag the wait 1 seconds block to the top of the stack, right under the green-flag block, so the order is now:

when [green flag] clicked
wait 1 seconds
move 50 steps
turn ↻ 90 degrees
move 50 steps

Click the green flag. What happened? The cat sits still for one second, then does the rest. Same blocks. Different order. Different behavior.

Try it again with the turn block at the very end, after both moves. Now the cat moves in a straight line and only turns when it's done. Same blocks. Different order. Different behavior.

This is the second-most-important rule of programming, after the peanut butter one:

Order matters. The same instructions in a different order make a different program.

Reset the cat

If your cat has wandered to a weird spot or is facing a weird way, that's fine — but it's annoying when you're trying to test your program. Two ways to reset:

• Click and drag the cat back to the middle of the stage with your mouse.
• Add a go to x: 0 y: 0 block (Motion, blue) at the very top of your program, right under the green flag. Now every time you click the green flag, the cat starts from the middle.

The second one is what programmers usually do: make the program reset itself. We'll come back to this idea a lot.

Checkpoint: You should have a program that starts with a green flag, includes at least three blocks in a row, and behaves differently when you change the order of the blocks. This is the natural stop point if class is cut short — Part B builds on this but isn't required.

Part B: A scripted scene

Now let's build something that feels like a tiny piece of a story.

What you're building

A short scene where the cat enters from the left side of the stage, walks to the middle, says "Hello!", waits, and walks off to the right side.

That's the base goal. It's a little harder than what we did in Part A because there are more steps and you have to think about positions and timing.

How to think about it

Before you start clicking, talk through it in plain words. What does the cat need to do, in order?

1. Start at the left side of the stage.
2. Walk to the middle.
3. Say "Hello!" for two seconds.
4. Wait a moment.
5. Walk off to the right.

That's a sequence. Now you need to find the right blocks.

• Start at the left side: go to x: -200 y: 0 (Motion). The stage is about 480 wide, so x = -200 is near the left.
• Walk to the middle: several move 10 steps blocks, or one glide 2 secs to x: 0 y: 0 block (also Motion). The glide version is smoother — try both and see which you like.
• Say "Hello!" for two seconds: say [Hello!] for 2 seconds (Looks, purple).
• Wait a moment: wait 1 seconds (Control).
• Walk off to the right: glide 2 secs to x: 240 y: 0.

Snap them all under your when green flag clicked block. Click the flag. Watch your scene.

Try the stretch goal

If your base scene works and you have time:

• Stretch: Add a second sprite — a person, a dog, anything from the sprite library. Have them say something back to the cat before the cat walks off. (Tricky part: you'll need to give the second sprite its own when green flag clicked block, because every sprite has its own scripts.)

Or the extension

If you finish stretch and still have time:

• Extension: Make the cat do a short dance in the middle of the scene. A dance is just a sequence — turn a little, move a little, turn back, move back, in some pattern that looks like dancing.

Don't worry about making it perfect. "Looks like dancing" is the goal, not "actual dance choreography."

Wrap-up

Before we leave, let's share:

• What did your scene do?
• Did anything happen that you didn't expect?
• Did you have to change the order of blocks to get something to work?

Done for today doesn't mean done with the topic. Sequences will come back every week from here on out. You'll get plenty more practice.

If you missed this session

Open Scratch on your computer. Start a new project. Then:

1. Drag a when green flag clicked block (yellow, Events) into the script area.
2. Snap a move 50 steps block underneath it.
3. Snap a wait 1 seconds block underneath that.
4. Snap a turn 90 degrees block underneath that.
5. Snap one more move 50 steps block underneath.
6. Click the green flag. Watch the cat.
7. Now drag the wait block to a different position in the stack. Click the green flag. Watch what changes.

Then try the scripted scene from Part B above. The base goal — cat enters, walks to middle, says hello, walks off — is the catch-up exercise. About 20 minutes of work.

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Use glide blocks instead of move blocks for smoother motion.
• Add a backdrop (look at the bottom-right corner, "Choose a Backdrop" button). Set the scene somewhere — a forest, a city, outer space.
• Make the cat change costume at some point in the scene. Sprites often have multiple costumes built in. Look at the Costumes tab at the top of the Scratch window.

What's next

Next week we'll learn about loops — how to make the cat do something twenty times without dragging twenty blocks.

Session 3: Loops — doing things over and over

Phase 1 — Scratch · Session 3 of 9

What we're learning today

Today you'll learn one of the most important ideas in all of programming: how to tell the computer to do something many times, without writing the same instruction over and over. This is called a loop. By the end of class, you'll have used a loop to make your cat draw a perfect square — and then you'll see how a tiny change to the loop turns the square into a triangle, a hexagon, or a flower.

You'll need to remember from last time

• Sequences — code runs in order, top to bottom.
• The green flag starts your program.
• The blocks move, turn, wait, and go to x: y:.
• Order matters.

Part A: Why loops exist

Open Scratch and start a new project. Add a when green flag clicked block, like always.

Now imagine you wanted to make the cat march in a straight line — take ten little steps, one after another. With what you know so far, you'd have to drag ten move 10 steps blocks and snap them all together.

Try it. Drag ten of them. It's tedious. Ten is annoying. A hundred would be ridiculous. A thousand would be impossible to build by hand.

Programmers ran into this problem about three seconds after they invented programming. The solution they came up with is the loop: a way to say "do this a bunch of times" without writing it out a bunch of times.

The repeat block

Delete the ten move blocks (right-click → delete, or drag them off to the left).

Now go to the Control category (orange blocks). Find this one:

repeat [10]
   <empty>

It's shaped differently from the blocks you've used so far — it has a mouth in the middle. Blocks go inside the mouth, and they'll run as many times as the number you put in the top.

Snap a move 10 steps block inside the mouth, and snap the whole repeat block under your when green flag clicked block. You should end up with this:

when [green flag] clicked
repeat [10]
   move 10 steps

Click the green flag. The cat takes ten steps in quick succession.

That's a loop. The move 10 steps block ran ten times.

Try changing the number

Click the 10 in the repeat block and change it to 100. Click the green flag. The cat zooms across the stage.

Change it to 3. Three little steps.

Change it to 1. Just one step. (A loop that runs once is silly, but the computer will obey.)

Change it to 0. The cat doesn't move. The loop runs zero times, which is allowed.

The number controls how many times the inside runs. That's the whole concept.

Multiple blocks inside a loop

You can put more than one block inside the mouth. Try this:

when [green flag] clicked
repeat [4]
   move 50 steps
   turn ↻ 90 degrees

Click the green flag.

Watch carefully. The cat moves 50 steps, turns 90 degrees, moves 50 steps, turns 90 degrees… four times.

What shape did the cat just walk?

A square.

You just told the computer to draw a square in three lines of code. Without the loop, you would have written the same two blocks four times — eight blocks instead of three. With a loop that ran 100 times, that would be 200 blocks instead of 3.

This is why loops are one of the most important ideas in programming.

Checkpoint: Every student should have built a repeat loop with at least one block inside it and clicked the green flag to see it run. This is the natural stop point if class is cut short.

Part B: Drawing with loops

Now we'll do something more visually satisfying than walking the cat in invisible squares. We'll have the cat actually draw the square as it walks.

Adding the Pen extension

Scratch has extra block categories called extensions that aren't shown by default. We need one called Pen to draw.

Look at the bottom-left corner of the Scratch window. There's a blue square with a + icon — the "Add Extension" button. Click it.

A list of extensions appears. Find the one called Pen and click it.

A new category called Pen (green) now appears in your blocks panel. You'll see blocks like pen down, pen up, set pen color, erase all, and a few others.

The way pen works: when pen down is active, the sprite leaves a trail behind it as it moves. When pen up, no trail.

Draw a square

Modify your loop program so it looks like this:

when [green flag] clicked
erase all
go to x: 0 y: 0
pen down
repeat [4]
   move 100 steps
   turn ↻ 90 degrees
pen up

Three new blocks at the top — erase all (so old drawings don't stick around), go to x: 0 y: 0 (so the cat starts in the middle), and pen down (so the trail starts). And one new block at the end — pen up (so we don't keep drawing if we add more code later).

Click the green flag. Watch the cat draw a square.

That, right there, is the moment programming starts to feel like a superpower.

Try the stretch

The base goal is the square above. If that works:

• Stretch: Change the repeat to 3 and the turn to 120 degrees. What shape do you get? Now try 5 and 72. Now try 6 and 60. There's a pattern. Can you figure it out?
• Hint: Look at the two numbers and how they relate. (If you want a really sneaky hint: 4 × 90 = 360. 3 × 120 = 360. 5 × 72 =
  360. The total turning is always 360 degrees, because that's a full trip around.)

Or the extension

If you finished stretch and want more:

• Extension: Use a nested loop — a loop inside a loop. The inner loop draws a shape; the outer loop turns a little and draws it again. Something like this: repeat [12] repeat [4] move 50 steps turn ↻ 90 degrees turn ↻ 30 degrees Click the green flag. You should get a beautiful flower-of-squares pattern.

Wrap-up

Before we leave, share with the room:

• What's the coolest shape you got the cat to draw?
• Did you try changing numbers and discover something unexpected?
• If you wanted to draw a 100-sided shape, what would the two numbers in your loop be? (You don't have to actually try it unless you want to. But predict.)

You've now used your first programming concept that isn't in the peanut butter rule. Loops are the first big idea where the computer does something you didn't tell it to do explicitly — it does the inside part many times because you set it up to. That's a real shift.

If you missed this session

Open Scratch and start a new project. Then:

1. Add a when green flag clicked block.
2. From the Control category, drag out a repeat 10 block. Snap a move 10 steps block inside its mouth. Snap the whole thing under the green flag. Click the green flag. The cat moves ten times in a row.
3. Change the inside to move 50 steps and turn 90 degrees, and change the repeat number to 4. Click the green flag. The cat walks a square.
4. Click the Add Extension button (bottom-left). Pick Pen.
5. Add erase all, go to x: 0 y: 0, and pen down to the top of your program (in that order). Click the green flag. The cat draws a square.

Then try Part B's stretch goal: change the numbers to draw a triangle, a pentagon, a hexagon. About 25 minutes of work.

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Use set pen color to (Pen category) to change the color of your drawing.
• Use set pen size to to make the lines thicker.
• Make a spiral by combining move and turn outside a loop: repeat [50] move 5 steps turn ↻ 10 degrees Each time around the loop, the cat takes a bigger and bigger swing. Actually no — wait, did it? Look carefully. The loop body is the same every iteration. So why does it look like a spiral and not a circle?
• Try using a forever block instead of repeat. (Hint: you'll need the red stop sign to make it stop.)

What's next

Next week we'll learn about events — how to make sprites react to keyboard presses, mouse clicks, and other things that happen while a program is running, not just when it starts.

Session 4: Events — making things happen when...

Phase 1 — Scratch · Session 4 of 9

What we're learning today

Up until now, all your programs started one way: you clicked the green flag. Today we'll learn how to make sprites react to other things — a key being pressed, a sprite being clicked, all kinds of moments while your program is running. These are called events, and they're how you go from "the program does its thing" to "I'm controlling the program in real time."

You'll need to remember from last time

• Sequences — code runs in order, top to bottom.
• The repeat loop — does the inside N times.
• Each sprite has its own scripts. When you switch sprites in the bottom-right panel, you see that sprite's scripts.
• The green flag is one kind of starter block. There are others.

Part A: More than one way to start

Open Scratch and start a new project.

So far, every program you've written starts with the same block:

when [green flag] clicked

That block is in a category called Events (yellow). It's not the only block in there. Take a look at the Events category. You'll see several other "when X happens" blocks. They all work the same way: when the thing happens, the script underneath runs.

The two we'll use today:

• when [space] key pressed — runs when you press the space key. (You can change which key it watches for by clicking the dropdown.)
• when this sprite clicked — runs when you click on the sprite with your mouse.

A sprite can have as many scripts as you want. Each one has its own starter block, and each one runs independently when its event fires.

Build your first multi-event sprite

Try this. Snap together three separate scripts on the cat:

when [green flag] clicked
go to x: 0 y: 0

when [space] key pressed
say [Hi!] for 1 seconds

when this sprite clicked
turn ↻ 30 degrees

These are three separate stacks of blocks, not one big stack. Don't try to snap them together. They each have their own starter and they live separately in your script area.

Now click the green flag. The cat goes to the middle.

Press the spacebar. The cat says "Hi!"

Click on the cat. It turns 30 degrees.

That's three different events triggering three different behaviors, all on one sprite.

Cat that walks with the arrow keys

Now let's make the cat respond to the arrow keys. We want:

• Right arrow: cat moves right
• Left arrow: cat moves left
• Up arrow: cat moves up
• Down arrow: cat moves down

That's four scripts. Each one is short:

when [right arrow] key pressed
change x by 10

when [left arrow] key pressed
change x by -10

when [up arrow] key pressed
change y by 10

when [down arrow] key pressed
change y by -10

change x by 10 (Motion category) shifts the sprite right by 10 units. change x by -10 shifts it left. Same idea for y, except y is up/down.

Build all four scripts. Then press the arrow keys.

Your cat now walks around the stage, controlled by you. You're not clicking blocks anymore — you're playing a tiny game with a cat you just programmed.

If the movement feels a little choppy when you hold an arrow key down — that's because the keyboard takes a moment before it starts "repeating" the keypress. We'll fix this in a later session. For now, quick taps work fine.

Checkpoint: You have a sprite with at least three separate scripts triggered by three different events (one of which is a keyboard event), and they all work. This is the natural stop point if class is cut short.

Part B: Two players, one stage

Now let's add a second sprite that responds to its own keys.

Add a second sprite

Look at the bottom-right corner of the Scratch window. Click the Choose a Sprite button (the cat-with-plus icon). Pick anything — a dog, a person, a robot. We'll use it as a second player.

When you add the new sprite, the scripts area in the middle of the screen switches to that sprite's scripts — which are empty right now. Notice the cat's scripts are still there; you just don't see them while you're looking at the dog. To switch back, click the cat in the bottom-right panel.

Give your second sprite WASD movement

While looking at the second sprite, build four scripts that mirror the cat's, but using W, A, S, D instead of arrow keys:

• when [w] key pressed → change y by 10
• when [a] key pressed → change x by -10
• when [s] key pressed → change y by -10
• when [d] key pressed → change x by 10

Click the green flag (or just start pressing keys).

Now you have two sprites controlled independently by two keyboards-worth of keys. Try it with a buddy: one of you uses arrow keys, the other uses WASD. You're both on the same stage at the same time.

This is the base goal. If you got that working, you're done for today.

Stretch goal

Make each sprite do something interesting when clicked. The cat might say something. The other sprite might change costume (look at the Costumes tab at the top of the Scratch window — many sprites come with multiple costumes).

Extension

Build a third sprite — a "ball" or "object" — that doesn't move on its own but does something when clicked. For example: when clicked, it teleports to a random spot using go to x: <pick random> y: <pick random> (you'll find pick random in the Operators category, the green blocks).

Now your two players can race to click the ball after it teleports. A tiny game.

Wrap-up

Before we leave, share with the room:

• What's something cool your sprites do that you didn't expect?
• If you and your buddy played the two-player WASD/arrows version, what was harder than you thought it would be?
• If you could add one more event to your sprite, what would it do?

You learned something important today that's not just about Scratch: a program can do many things in response to many different triggers, all at once. Real apps work this way. When you click something on a website, that's an event. When you press a key in a game, that's an event. You now know what's happening underneath.

If you missed this session

Open Scratch and start a new project. Then:

1. Look at the Events category (yellow blocks). Drag out a when [space] key pressed block.
2. Snap a say [Hi!] for 1 seconds block under it. Press the spacebar to test.
3. Drag out a when this sprite clicked block. Snap a turn 15 degrees block under it. Click the cat to test.
4. Now build the four arrow-key movement scripts described in Part A above (right, left, up, down). About 10 minutes.
5. Then try Part B — add a second sprite, give it WASD movement.

When you come next week, you'll be ready. If anything's confusing, ask your buddy at the start of class.

Stretch and extension ideas

• Use when [any] key pressed to make a sprite react to any key. Useful for "press any key to start" effects.
• Use start sound (Sound category) to play a sound when an event fires. Several sprites come with sound effects built in.
• Add a backdrop to your scene (bottom-right "Choose a Backdrop" button). Doesn't change behavior, but makes everything look like it belongs somewhere.

What's next

Next week we'll learn about conditionals — how to make your sprites decide what to do based on what's happening, like "bounce if you hit the wall" or "say 'caught!' if you touch the apple."

Session 5: Conditionals — making decisions

Phase 1 — Scratch · Session 5 of 9

What we're learning today

So far your programs have always done the same thing every time they ran. Today we'll learn how to make a program check something about the world — "is the cat touching the apple?" — and decide what to do based on the answer. This is called a conditional, and combined with everything you already know, it's enough to build your first real game.

You'll need to remember from last time

• Events — when [key] pressed, when this sprite clicked.
• Each sprite has its own scripts.
• Sequences run top to bottom; loops repeat.
• The arrow-key cat you built last week (or its equivalent in the catch-up exercise).

Part A: "If something, then do this"

Open Scratch and start a new project.

A conditional is the programming idea of "check first, then decide." In English you use them all the time: "if it's raining, take an umbrella." The "check" is is it raining? The "decision" is take an umbrella, or don't.

Scratch has a block for this. It's in the Control category (orange):

if < > then
   <empty>

Like the repeat block, it has a mouth. Things go inside the mouth, and they only run if the condition (the thing in the diamond at the top) is true.

The diamond shape at the top of the if block is a slot for a condition — a question Scratch can answer with yes or no. To fill the slot, you need a block that's also shaped like a diamond.

Take a look at the Sensing category (light blue). Notice that some blocks there are diamond-shaped:

• <key [space] pressed?> — answers "is the space key being pressed right now?"
• <touching [Sprite1]?> — answers "is this sprite touching that other sprite?"
• <touching color []?> — answers "is this sprite touching that color?"
• <mouse down?> — answers "is the mouse button being held?"

Each of those answers yes-or-no. You drop one into the diamond slot of an if block, and the inside runs only when the answer is yes.

Smooth movement (a callback to last week)

Remember how your cat felt a little choppy when you held down the arrow key? Conditionals fix that.

Last week you built four scripts, one per arrow key. This week we'll build one script, with conditionals inside a forever loop.

Add a cat to your project (it should be there by default). Build this:

when [green flag] clicked
forever
   if <key [right arrow] pressed?> then
      change x by 5
   if <key [left arrow] pressed?> then
      change x by -5
   if <key [up arrow] pressed?> then
      change y by 5
   if <key [down arrow] pressed?> then
      change y by -5

Four if blocks, all stacked inside a forever loop, all under one green flag.

The forever block (Control, orange) is the loop equivalent of "keep doing this until I stop you." Inside it, every fraction of a second, Scratch checks all four if blocks. If an arrow key is being held down, the corresponding change block runs — that fraction of a second, every fraction of a second, while the key is held.

Click the green flag. Hold an arrow key. The cat moves smoothly, because every fraction of a second the program is asking "is this key pressed?" and acting on the answer.

That's the same arrow-key movement you built last week, but now it feels right. That's the power of conditionals plus loops.

Checkpoint: Your cat moves smoothly with the arrow keys when you hold them down, using a single forever loop with four if blocks inside. This is the natural stop point if class is cut short.

Part B: Catch the apple

Now we'll build something that actually feels like a game.

What you're building

An apple sprite falls from the top of the stage. Your cat moves along the bottom (using your smooth arrow-key movement from Part A). When the cat catches the apple, the apple says "Yum!" and goes back to the top to fall again.

It's a tiny game. You'll know if you can catch the apple or not. That's the whole point.

Set up the stage

You already have your cat with smooth arrow-key movement. Two small adjustments:

• Move the cat to the bottom of the stage. Add go to x: 0 y: -130 inside the when green flag clicked script (above the forever loop). Now the cat starts near the bottom every time.
• For this game, the cat only needs to move left and right. You can delete the up arrow and down arrow if blocks if you want, or leave them — your choice.

Add the apple

Click the Choose a Sprite button (bottom right). In the search box, type "apple." Pick any apple-looking sprite. (Don't see one? Any small sprite works. Pick a fruit, a ball, anything that can "fall.")

Make sure you're now editing the apple's scripts (click the apple in the bottom-right panel; the script area should be empty).

Build this on the apple:

when [green flag] clicked
go to x: pick random -200 to 200 y: 180
forever
   change y by -3
   if <touching [Sprite1] ?> then
      say [Yum!] for 1 seconds
      go to x: pick random -200 to 200 y: 180

A few things to notice in this script:

• pick random -200 to 200 is in the Operators category (the green blocks). It's another diamond-shaped block, but it goes into the x slot of go to because that slot accepts numbers. It picks a random x-coordinate each time, so the apple appears somewhere different.
• Sprite1 is the cat's name. Scratch may have renamed it; if your cat is called something else (like "Cat"), pick that name from the dropdown.
• The script flow: the apple starts at a random spot at the top (y = 180 is near the top), then forever it falls (changes y by -3), and on every fall it checks "am I touching the cat?" If yes, it says "Yum!" and resets to the top.

Click the green flag. The apple falls. Move the cat with the arrow keys. Catch it.

You just built a game.

That's the base goal. If you got the apple to fall, the cat to catch it, and the apple to reset — you're done for today.

Stretch goal

What happens when the apple reaches the bottom of the stage and the cat didn't catch it? Right now: it just keeps falling forever and disappears off screen. That's not great game design.

Add a "missed!" condition. Inside the forever loop, after the existing if, add another:

if <(y position) < -180> then
   say [Missed!] for 1 seconds
   go to x: pick random -200 to 200 y: 180

y position is in the Sensing category (it's not a diamond — it's a rounded block, because it returns a number, not a yes/no answer). The <> comparison is in the Operators category — look for < in the green blocks.

Now if the apple falls past the bottom of the stage (y < -180), it says "Missed!" and resets to the top. The game has a real "miss" condition.

Extension

Add a second falling object. A different fruit, a coin, anything. Make it fall faster (or slower) than the apple. The cat now has to catch both, possibly making choices about which to chase.

To add it: the new sprite is just another sprite. Build the same "forever fall + if touching cat then yum + reset" script on it. The only thing you change is the speed (change y by -5 instead of -3, for instance).

Two falling sprites at different speeds is twice as hard. Your buddy can play it.

Wrap-up

Before we leave, share with the room:

• Did anyone catch the apple ten times in a row? Five?
• What was the trickiest part of getting the apple to reset correctly?
• For the kids who did the stretch — what made you decide what number to use for "the bottom of the stage"?

You did something bigger today than just learning conditionals. You combined events (arrow keys), loops (forever), and conditionals (if touching) to build something that looks and feels like a real game. Every game you'll ever play uses these three ideas, just with more sprites and more conditions.

You're not even halfway through Phase 1, and you already have everything you need to build games.

If you missed this session

Open Scratch and start a new project. Then:

1. Build the smooth arrow-key cat from Part A (one forever loop, four if blocks). About 10 minutes.
2. Add an apple sprite (or any sprite that can "fall").
3. Build the apple's falling-and-resetting script described in Part B above. About 15 minutes.
4. Click the green flag. Move the cat. Try to catch the apple.

When you come next week, you'll be ready. If anything's confusing, ask your buddy at the start of class.

Stretch and extension ideas

• Use if/else (Control category — like if, but with two mouths). Lets you do "if X then this, otherwise that" in one block. More elegant than two if blocks for the same situation.
• Make the apple change costume when caught, then change back when it resets. (Look at the apple's Costumes tab; try next costume.)
• Use start sound (Sound category) to play a sound when the cat catches the apple.
• Add a wait 0.05 seconds block at the end of the apple's forever loop. What changes? Why?

What's next

Next week we'll learn about variables — how to make Scratch remember things, like a score. That'll let you finally turn your catch-the-apple game into a real game with points.

Session 6: Variables — remembering things

Phase 1 — Scratch · Session 6 of 9

What we're learning today

Today you'll learn how to make Scratch remember a number — like a score, a count, or a level. Once you can do that, you can finally turn last week's catch-the-apple game into a real game with a score on the screen that goes up every time you catch one. The thing that makes Scratch remember is called a variable, and it's one of the ideas you'll use in every program you ever write.

You'll need to remember from last time

• Conditionals (if blocks) and the forever loop.
• Sensing blocks like <touching ...?>.
• The catch-the-apple game you built last week (or its catch-up version).

Part A: A box with a number in it

Open Scratch and start a new project. Keep the cat.

A variable is the programming word for "a labeled box that holds something." You give the box a name, you put a number in it, and you can change the number whenever you want. The computer remembers what's in the box for as long as your program is running.

Real-world example: the score in a basketball game is a variable. It starts at 0. Every time a team scores, the number goes up. The scoreboard remembers it. That's all a variable is.

Make your first variable

Look at the Variables category in the blocks panel (orange — but a different orange from Control). At the top of it, there's a button called Make a Variable. Click it.

Scratch asks for a name. Type clicks. Leave the rest at the defaults (For all sprites). Click OK.

Several things just happened:

• A new set of blocks appeared in the Variables category, all related to your clicks variable.
• A small display labeled "clicks" appeared in the top-left corner of the stage. That's your variable's value, shown in real time. Right now it shows 0.

Use the variable

Build this on the cat:

when [green flag] clicked
set [clicks] to 0

when this sprite clicked
change [clicks] by 1

Two scripts. One resets the variable to 0 when you click the green flag. The other adds 1 to the variable every time you click the cat.

Click the green flag. The display shows 0.

Click the cat. The display shows 1. Click again. 2. Again. 3.

You just made the computer remember something. Every click adds one. The variable holds the running total.

Click the green flag again. Back to 0. Click the cat. 1 again. The variable resets when you start over, then counts up from there.

Show the variable to the cat

You can also use the variable's value inside other blocks. Add a third script:

when [space] key pressed
say (clicks) for 1 seconds

The (clicks) block (rounded, in Variables — it's the rounded one right next to your variable name) gives you the current value.

Click the green flag. Click the cat a few times. Press space. The cat says the current value out loud. Click the cat more. Press space again. The cat says the new value.

That's the three things you do with a variable: set it, change it, and read it.

Checkpoint: You have a variable that increases when you click the cat, resets when you click the green flag, and is displayed by the cat when you press space. This is the natural stop point if class is cut short.

Part B: Score in your catch-the-apple game

Now we'll add a score to the game from last week.

Open last week's project

Open the catch-the-apple project from Session 5. (If you don't have it — for example because you missed last week — go back to Session 5 and build the base game first, or use the catch-up version.)

You should have a cat that moves with the arrow keys (smooth movement, with a forever loop and four if blocks) and an apple that falls from the top, says "Yum!" when the cat catches it, and resets to a random spot at the top.

Add a score variable

Click Make a Variable in the Variables category. Name it score. Click OK. The score display appears in the top-left of the stage.

Reset the score on green flag

The cat already has a when green flag clicked script. Add to it:

when [green flag] clicked
go to x: 0 y: -130
set [score] to 0
forever
   if <key [right arrow] pressed?> then
      change x by 5
   if <key [left arrow] pressed?> then
      change x by -5

(Just add set [score] to 0 somewhere before the forever loop.)

Make the apple update the score

Click the apple sprite in the bottom-right panel to switch to its scripts. Find the part where it says "Yum!" and resets to the top. Add change [score] by 1 to that block:

when [green flag] clicked
go to x: pick random -200 to 200 y: 180
forever
   change y by -3
   if <touching [Sprite1] ?> then
      change [score] by 1
      say [Yum!] for 1 seconds
      go to x: pick random -200 to 200 y: 180

Click the green flag. Catch the apple a few times.

The score in the corner goes up every time. You're keeping score in your own game.

That's the base goal.

Stretch goal

Add a "missed" penalty. If the apple falls past the bottom of the stage without being caught, decrease the score by 1.

Find the if <(y position) < -180> block from last week's stretch goal (or add it now). Inside it, add change [score] by -1. So:

if <(y position) < -180> then
   change [score] by -1
   say [Missed!] for 1 seconds
   go to x: pick random -200 to 200 y: 180

Now your score reflects skill — catches add, misses subtract. Carelessness costs you points.

Extension

Add a second variable called best. Whenever score goes higher than best, update best. The display now shows two numbers: your current score, and the best score you've gotten this session.

Add this to a forever loop somewhere (maybe on the cat):

forever
   if <(score) > (best)> then
      set [best] to (score)

The <> comparison is in Operators (green). The (score) and (best) rounded blocks are in Variables.

Now you have a "personal best" tracker. It resets when you click the green flag, but within a single play session, it keeps the high score visible.

Wrap-up

Before we leave, share with the room:

• What's the highest score you got? Did anyone beat it after another few tries?
• For the kids who did the missed-penalty stretch — does it feel like a different game when there's a real consequence for missing?
• What's another game where the score would matter?

You learned the simplest version of one of the biggest ideas in programming: state. Programs that remember something — anything — between one moment and the next are running on state. Every website that knows you're logged in, every game that tracks your progress, every app that holds a counter — all of it is variables, behind the scenes.

You also closed the loop on something. Your game from last week was missing one important piece, and now it has it. Real software gets built that way: ship something, play with it, find what's missing, add it, repeat.

If you missed this session

Open Scratch and start a new project. Then:

1. Click Make a Variable in the Variables category. Name it clicks. Click OK.
2. Build the two scripts from Part A: green-flag-resets-to-0, and sprite-clicked-changes-by-1. Click the cat to test.
3. Open your catch-the-apple project from Session 5 (or build the catch-up version of Session 5 first if you don't have one).
4. Add a score variable. Reset it to 0 on green flag. Have the apple's "if touching cat" block also change score by 1. Click the green flag and play. Score goes up each catch.

About 25 minutes of work total.

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Show the variable in a "large" view — right-click on the variable display on the stage and pick "large readout." Looks more like a real scoreboard.
• Make a "level" variable that increases every time the score hits a multiple of 10. Display both score and level.
• Use hide variable [name] (Variables category) to hide a variable from the stage when you don't want players to see it. Useful for variables you're tracking internally but don't want shown.
• Tinker with the set vs change distinction. Try set score to 10 and watch the score jump. The difference between "put this exact number in the box" and "add this number to whatever's in the box" is worth feeling.

What's next

Next week we'll put everything together — sequences, loops, events, conditionals, sensing, variables — and build a single small game that uses all of it. After that, you'll plan and build your own milestone project.

Session 7: Putting it together — a small game

Phase 1 — Scratch · Session 7 of 9

What we're learning today

You've now learned every basic idea you need to build games: sequences, loops, events, conditionals, sensing, and variables. Today we'll combine all of them into one small game called Apples and Rocks — catch the falling apples for points, but dodge the falling rocks or it's game over. By the end, you'll have a complete, playable game with a score and a real losing condition.

You'll need to remember from last time

• Variables — set, change, (read), displayed on stage.
• The if block + sensing for collision detection.
• Forever loops for things that keep happening.
• Events for arrow-key control.
• Multiple sprites with their own scripts.

That's basically the whole curriculum so far. Today is the test: can you put it all together?

Part A: Build the basic game (apples falling, score going up)

Open Scratch and start a new project. (Don't open last week's — we'll build the whole game from scratch so you remember every piece.)

This first half is essentially the catch-the-apple game from Sessions 5 and 6, rebuilt cleanly in one go. If you've kept up, this should feel like review. That's the point — you're proving to yourself that you can build this from memory.

Anatomy of this game (how the parts fit together)

Before you start clicking blocks, look at the shape of what you're building. Three sprites, each with its own job:

Cat sprite (the player)
  on green flag:
    [reset position, reset score]
    forever:
      [if right arrow → move right]
      [if left arrow → move left]

Apple sprite (the good thing)
  on green flag:
    [start at top, random x]
    forever:
      [fall down]
      [if touching cat → +1 score, restart at top]
      [if off bottom → restart at top]

Rock sprite (the bad thing) — added in Part B
  on green flag:
    [start at top, random x]
    forever:
      [fall down]
      [if touching cat → say "Game Over!", stop everything]
      [if off bottom → restart at top]

Each sprite is a tiny machine that runs forever once you press the green flag. They don't know about each other except through touching checks. Keep this map in your head as you build.

Set up the cat

Build this on the cat:

when [green flag] clicked
go to x: 0 y: -130
set [score] to 0
forever
   if <key [right arrow] pressed?> then
      change x by 7
   if <key [left arrow] pressed?> then
      change x by -7

(Make a score variable first if you haven't — Variables category → Make a Variable → name it score → OK.)

The cat sits at the bottom of the stage and slides left/right with the arrow keys. Score resets to 0 on green flag.

Add the apple

Click Choose a Sprite (bottom right). Search for "apple" and add one (or any small fruit/food sprite).

Switch to the apple's scripts (click the apple in the sprite list). Build:

when [green flag] clicked
go to x: pick random -200 to 200 y: 180
forever
   change y by -3
   if <touching [Sprite1] ?> then
      change [score] by 1
      go to x: pick random -200 to 200 y: 180
   if <(y position) < -180> then
      go to x: pick random -200 to 200 y: 180

(Replace Sprite1 with whatever your cat is named in the dropdown. Often it's Cat or Sprite1.)

The apple falls, gives you a point if the cat catches it, resets to the top either way (catch or miss).

Click the green flag. Move the cat. Catch some apples. Watch the score go up.

This is the base game — same as before, just rebuilt cleanly.

Checkpoint: You have a working catch-the-apple game with a visible score that increases when the cat catches apples. This is the natural stop point if class is cut short — Part B adds the hazard mechanic but isn't required.

Part B: Add the rock (game over!)

Now we'll make this a real game by adding risk. Right now you can just stand still and you don't lose anything. Boring. Time to add a falling rock that ends the game if you touch it.

Add the rock sprite

Click Choose a Sprite again. Search for "rock" — there's a Rocks sprite in the library. (Or pick anything that looks like something you wouldn't want to touch — a bug, a skull, a "Block.")

Switch to the rock's scripts. Build:

when [green flag] clicked
go to x: pick random -200 to 200 y: 180
forever
   change y by -3
   if <touching [Sprite1] ?> then
      say [Game Over!] for 2 seconds
      stop [all]
   if <(y position) < -180> then
      go to x: pick random -200 to 200 y: 180

The rock falls just like the apple, but:

• If it touches the cat: say "Game Over!" for 2 seconds, then stop [all] (Control category) — this freezes the entire program.
• If it falls off the bottom: reset to top with new random x. (No penalty for letting a rock pass — that's actually what you want to happen.)

Click the green flag. Move the cat. Catch apples. Dodge the rock.

When the rock catches you, the cat says "Game Over!" and everything freezes. Your final score sits on the screen as your record.

You just built a game with a real losing condition. Welcome to actual game design.

That's the base goal for today. If your apples-and-rocks game runs and ends correctly, you're done.

Stretch goal

Right now the apple and the rock fall at the same speed. Make the rock slightly faster than the apple to ramp up the challenge:

In the rock's forever loop, change change y by -3 to change y by -4 or -5. Now the rock is harder to dodge.

Then make a second apple sprite (right-click the apple in the sprite list → duplicate). Two apples falling at once means more points but also more places to be at the wrong moment.

Extension

Add a "best" score variable that survives across plays in the same session. Add to the cat's scripts:

when [space] key pressed
if <(score) > (best)> then
   set [best] to (score)

(You'll need to make a best variable first.)

Now: when you press space at the end of a game (after game over), your score gets compared to best, and best updates if you beat it. Across multiple games, you can keep trying to beat your own record. Press the green flag to start over each time.

For an even bigger challenge: what if score went DOWN by 1 each time the apple falls without being caught? Add change [score] by -1 inside the apple's (y position) < -180 block. Now you can have a negative score, and missing apples is genuinely costly.

Wrap-up

Before we leave, a few things to share:

• What was the highest score anyone got before the rock caught them?
• Did the rock-faster-than-apple stretch make the game feel meaningfully different?
• For the kids who did the "best" extension — does adding a high score change how you play?
• Did anything break in surprising ways while you were building it? This is the most important question. Programmers spend most of their time fixing things that broke. Your stories matter.

You did something today that you couldn't have done six weeks ago. You took a blank Scratch project and built a complete game that has a goal, a challenge, scoring, and a way to lose. Every video game you've ever played has those four things. You now know how to put them in something you built.

Looking ahead to your own project

Next week we start your milestone project — your game, your idea, your design. You'll have two weeks to plan, build, and polish, then you'll show it to the class.

Start thinking now: what do you want to make? Some ideas to get you started:

• A different kind of catch game (catching different things, different objectives)
• A maze game where the cat has to reach a goal without touching the walls
• A drawing toy (using the pen extension from Session 3)
• A mini-quiz where the cat asks questions and reacts to clicks
• A "boss battle" where you click a sprite many times to defeat it
• An interactive story — multiple sprites, multiple scenes, the user clicks to advance
• Anything else you can imagine that uses what you've learned

You don't have to decide today. But come to next week's class with at least one idea you're excited about.

If you missed this session

Open Scratch and start a new project. Then:

1. Build the cat with smooth left/right movement at the bottom of the stage. Reset score to 0 on green flag. (Part A above.)
2. Add an apple that falls, gives a point on catch, resets either way.
3. Add a rock that falls. If it touches the cat: say "Game Over" for 2 seconds, then stop [all]. If it falls off the bottom: reset to top.
4. Test it. Catch apples. Try to dodge the rock.

About 30-40 minutes of work.

Then think about what you want to build for your own project next week. Bring an idea.

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Add a backdrop (bottom-right Choose a Backdrop button) so the game has a setting — a forest, a city, outer space.
• Add a sound effect when the cat catches an apple. (Sound category, start sound. Some apple sprites come with sound effects built in.)
• Make the cat change costume when game over fires (look at the Costumes tab — many cats have multiple costumes).
• Add a third "good" sprite (a star, a heart) worth more points than the apple. Now you have to choose what to chase.

What's next

Next week is the start of your milestone project — two weeks to plan, build, and polish your own game. Bring an idea or two. The final week will be a class demo day where everyone shows what they built.

Session 8: Milestone project work day 1

Phase 1 — Scratch · Session 8 of 9

What we're learning today

Today is your day. You're going to plan a game of your own choosing, then start building it. There's no new programming concept this week — instead, you'll use everything you've learned to make something that's yours, not your instructor's. Next week you'll finish it and show it to the class.

You'll need to remember from last time

• Everything from Sessions 1-7. No, really. Sequences, loops, events, conditionals, sensing, variables. You'll use all of them.
• Apples and Rocks from Session 7 — proof that you can build a complete game. If you built it, you can build something else too.
• The idea you brought with you today. (If you didn't bring one, that's okay — Part A will help.)

Part A: Plan your game

The most important thing a programmer does isn't typing code. It's deciding what to build before they start. Real software projects fail far more often because nobody decided what they were building than because the code was hard. Today you'll do the planning step.

The plan

Take a piece of paper (or open a text editor). Answer these questions about your game. Don't think too hard yet — first answers are usually fine.

1. What's the name of your game? (Make one up. You can change it later. Examples: "Donut Drop," "Cat vs. Asteroids," "The Royal Quest.")

2. In one sentence, what is your game? (Try to fit it on one line. Example: "You're a wizard catching falling books to build a tower.")

3. What sprites do you need? (List them. Example: "Wizard sprite, three book sprites, a tower-base backdrop.")

4. What does the player do? (How do they control things? Arrow keys? Click sprites? WASD? Some combination?)

5. What's the goal? (How does the player know they did well? Score that goes up? Reach a place? Survive a long time?)

6. What can go wrong? (How does the game end, or get harder? Game over? Missed too many? Time runs out?)

7. What's the simplest version that's still fun? (This is the most important question. If you only had today and next week to build this, what would you do FIRST? What would you add LATER if there's time?)

Talk it over with your buddy

Spend 5 minutes telling your buddy about your plan. Then your buddy tells you about theirs. Each of you says one thing about the other's plan — could be a question ("how does the player restart?") or a suggestion ("you could add a sound when they win!") or just an observation ("that sounds fun"). One thing. Don't redesign each other's games.

Show your instructor

When your plan is ready, show it to your instructor. He'll either say "go build it" or ask one question that helps you tighten it up. If he asks a question, that's not a bad thing — it means there's something worth thinking about for two more minutes.

Checkpoint: You have a written plan with all seven questions answered, and your instructor has signed off on it. This is the natural stop point if class is cut short — you can start building next week, and you've done the most important thing already by planning.

Part B: Start building

Now you build. The rest of class is yours.

Where to begin

Don't try to build everything at once. Real programmers build the simplest version that works first, then add to it. Look at your answer to question 7 above — that's where to start.

If your game is "wizard catches falling books," the simplest version is:

1. Wizard sprite that moves with arrow keys.
2. One book sprite that falls.
3. When the wizard touches the book, score goes up.

That's it. Then add a second book. Then add a way to lose. Then add the tower visual. Then add sounds. Each step works before the next one starts.

This is called iterative building and it's the secret most programmers wish they'd learned earlier. Build small. Test it. Build more. Test it. Repeat.

When you get stuck

When (not if) you get stuck:

1. Read your code carefully. Did you tell the computer the exact thing you meant? (Remember the peanut butter problem.)
2. Ask your buddy. They might see something you don't.
3. Look at how you did something similar before. If the apple in Apples and Rocks worked the way you want, copy that pattern.
4. Ask your instructor. Last resort, after the first three.

Getting stuck is normal. Programmers spend most of their time stuck. The skill isn't avoiding stuck — it's getting unstuck.

Wrap-up

Last 5 minutes: each of you, in one sentence, tell the room one thing you got working today in your project. Could be a sprite that moves. Could be a score that updates. Could be a backdrop that loads. Whatever's working — that's a win.

Don't worry if you didn't get as far as you wanted. Most projects take longer than the plan said they would. That's why the plan asked about the simplest version first — so you'd have something working even if you ran out of time.

Bring your project file (or just your machine if it's your class computer) next week. We'll finish, then demo to the class.

If you missed this session

Open Scratch and start a new project. Then:

1. Spend 10-15 minutes answering the seven planning questions above on paper or in a text file.
2. Start building the simplest version of your game (look at your answer to question 7).
3. When you come next week, you'll be ready to keep building.

If you don't have an idea, here are some starting points:

• A different falling-things catcher (catching donuts, coins, letters of the alphabet)
• A maze game where the player has to reach a target
• A pet care game (click the sprite to "feed" it; a hunger variable goes down over time)
• A whack-a-mole game (a sprite appears at random spots; click it before it disappears)
• A tiny choose-your-own-adventure (sprite asks a question, you click left or right side of the screen, the story branches)

Any of those can be built with what you know. Pick one and modify it — make it your own. Don't just copy.

Stretch and extension ideas

If your base game is working and you want to add more:

• A second screen — use a backdrop change at game over so the player sees a different background.
• Multiple difficulty levels — a variable that controls how fast things fall, increased by score.
• A start screen — when the green flag is clicked, show instructions until the player presses space, then start the game.
• Sound effects for important moments (catch, miss, game over).
• A costume change for any sprite at an interesting moment.

Whatever you add, add it one piece at a time and test after each piece. Big changes that touch many things are how games break.

What's next

Next week you'll have time to finish, polish, and demo your game to the rest of the class. Each person will get 3-5 minutes. Don't worry — it's a friendly demo, not a test. Bring a working game, bring your enthusiasm, and the rest takes care of itself.

Session 9: Milestone project work day 2 + demo day

Phase 1 — Scratch · Session 9 of 9

What we're learning today

Today is the last session of Phase 1. You'll spend the first half finishing and polishing your game — fixing bugs, adding the last features, making sure it runs. Then in the second half, you'll demo your game to the class. Everyone will see what everyone else made. By the end of class, you'll have shipped your first programming project.

You'll need to remember from last time

• Your project plan from Session 8.
• Whatever you got working last week — the foundation we'll finish on today.
• Your buddy — they'll help you test your game one last time before the demos.

Part A: Final polish

You have about 30-40 minutes to finish your game. Be honest with yourself about what's left to do.

What "finished" means

A finished milestone project is:

1. It runs. You can click the green flag and play it without crashing or getting confused.
2. It does what your plan said it would do — at least the base version (your answer to question 7 from Session 8).
3. You can explain how it works. If someone asks "how does the score get updated?" you can walk them through it. (Remember the "explain how it works" rule.)

If your game doesn't meet all three of those, focus on getting it there before adding anything new. A working basic game is way better than a broken ambitious one.

Check it with your buddy

About 15 minutes in, swap with your buddy. They play your game for two minutes; you play theirs. Notice:

• Did it work without help?
• Did anything break or do something unexpected?
• Could they tell what to do without instructions?

Tell each other what you noticed. This is the most useful feedback you'll get on your project, because your buddy is seeing your game with fresh eyes.

Remember the peanut butter

It's been eight weeks since the first session. Take a moment to remember:

Way back in Session 1, you couldn't even tell your instructor how to make a peanut butter and jelly sandwich. The computer is just like your instructor was that day — except the computer doesn't know what bread is.

You spent eight weeks getting better and better at telling that extremely stupid (and extremely literal) computer exactly what to do. Today, you're going to show the room a game that you built — that runs because you gave the computer instructions precise enough to follow.

That's a big deal. Sit with that for a second.

Checkpoint: Your game runs the basic version of what you planned, and you and your buddy have each played each other's games once. This is the natural stop point if class is cut short — but for today, we're going to keep going to the demo half.

Part B: Demo day

This is the fun part. Each of you will get 3-5 minutes to demo your game to the class.

How a demo works

When it's your turn:

1. Show your game. Play it for a minute or two. Let people see what it does. (You can also let someone else play it if you want.)
2. Tell us about it. What's it called? What were you trying to make? What's the goal of the game?
3. Tell us one thing that was hard. Not bragging — just honest. "Getting the score to reset was tricky." "I couldn't figure out how to make the rock spawn at random spots at first." Things that broke and how you fixed them.
4. Take one question. Someone in the room will ask one question — about how you built it, why you chose what you chose, what you'd add next. Answer it as best you can. "I don't know, I just tried things until it worked" is a great answer.

How to be a good audience

When it's not your turn:

• Watch. Pay attention to what other people made.
• Be ready to ask one question when it's your turn to ask. Good questions are specific — "how did you make the dragon breathe fire?" is way better than "that was cool, how'd you make it?"
• Be encouraging. your instructor will say something specific about each project at the end, and you can do the same as a buddy comment. "I really liked the part where the music changed when you scored" is way more useful than "good job."

After everyone demos

Your instructor will say a few things about each of you and what he saw across the projects. Then we're done — Phase 1 is over.

What you accomplished today

• You shipped a project. You took an idea, planned it, built it, and showed it to people. Most adults never do that. You just did it twice (once with Apples and Rocks, once with your own game).
• You gave a demo. Talking about what you made — what you intended, what was hard, what you'd do next — is a real career skill. Engineers do this every week. You just did it.
• You finished Phase 1. That's eight weeks of programming. You know sequences, loops, events, conditionals, sensing, variables, and how to combine them all into something playable. That's a real foundation.

What's next

Next week we start Phase 2 — Python. Scratch is great for learning the ideas of programming, but it's not what most programmers actually use day-to-day. Phase 2 introduces you to Python, a real programming language that grown-ups use to write everything from games to websites to scientific tools.

The first Python session uses something called Turtle — it's a tool where you write Python code and a little arrow on the screen draws shapes for you. Familiar territory (drawing with code, like the pen extension in Session 3) but in real Python syntax.

You'll start typing instead of dragging blocks. It feels different at first. That's okay. The thinking is the same — sequences, loops, conditionals, all of it carries over. The peanut butter rule definitely carries over.

Bring your curiosity. See you next week.

If you missed this session

Two cases:

If you missed only the demo half: Show your game to your instructor at the start of next week's class. He'll give you the same kind of feedback the demo would have. You won't have missed anything content-wise.

If you missed the whole session and don't have a finished project: No big deal. You can finish your project at home (reference the Session 8 plan you wrote) and bring it next week. Or just join us in Phase 2 — your Apples and Rocks game from Session 7 already counts as a project you built.

Stretch and extension ideas

If you have time after the demos and want to keep going:

• Polish your game more. Add a backdrop, sounds, a start screen. Make it look nice.
• Build a second game. With everything you know now, the second game is faster than the first. Try a different style — if you made a catcher, try a maze. If you made a clicker, try a dodger.
• Show your game to your family. They will be impressed. This is a fact.
• Save your project file. You'll want it later. By the time you finish Phase 8, you'll be amazed how far you came.

What's next

Next week starts Phase 2: Python with Turtle. Real code, real syntax, same thinking. Bring your machine and your brain.

Phase 2 — Python with Turtle

You finished Phase 1. You built a game in Scratch. You can think like a programmer. Now we switch to a real programming language: Python.

What this phase is

Phase 2 is the bridge between Scratch and the rest of the curriculum. The big shift this phase is typing instead of dragging. The blocks are gone. You'll type real Python code into a real editor, save it as a real file, and run it.

To make the shift gentler, we're not jumping straight into "all of Python." Instead, we use a tool called Turtle — it's part of Python itself, and it lets you draw on the screen by giving commands to a little arrow (a turtle). Like the pen extension in Scratch, but in Python.

By the end of Phase 2, you'll be writing real Python programs that draw real things, and the typing-not-dragging shift will feel normal. After this phase, the rest of the curriculum is all in Python.

What you'll learn

A lot of these ideas (sequences, loops, conditionals, variables) are familiar from Phase 1. What's new is the syntax — how you type each idea in Python. The biggest brand-new idea is functions in Session 4. We saved that one for Python on purpose.

What you'll build

Each session ends with a small drawing — shapes, scenes, patterns. By Session 7 you'll be making creative compositions that combine loops, functions, and color in ways that would have been impossible with Scratch's pen extension.

The milestone project in Session 8 is your own Turtle drawing — a pattern, a picture, a scene, a name in big letters, anything you can imagine. You'll plan it, build it, and demo it to the class.

What you'll need

• The same machine you used in Phase 1.
• Thonny — the Python editor. Pre-installed on your class computer. If you're working at home, the Installing on your own computer appendix tells you how to get it.
• The turtle module — comes with Python. No install needed.
• Patience. Typing precise code feels weird at first. It gets better fast.

How sessions work

Same shape as Phase 1:

• Part A introduces a new idea with a guided exercise. Stands alone if class gets cut short.
• Part B is open practice or a project. Often tiered (base / stretch / extension).
• Wrap-up to share what you did.

What's a little different in Phase 2: there will be error messages. A lot of them. Read them slowly. They're trying to help. The Reading error messages appendix will get fleshed out as we encounter common ones.

A note about typing

If you're a slow typist, that's okay. Programming isn't about typing speed — it's about thinking clearly. Most professional programmers type around the same speed as a careful average person. What matters is being precise. A typo is a bug, and fixing typos is a real part of programming.

If your typing feels slow enough to be frustrating, mention it to your instructor. He can suggest some ways to practice between classes. But it's not a barrier — kids with all kinds of typing speeds finish this curriculum.

Where to start

Session 1: Welcome to Python — typing instead of dragging is where Python begins.

When you're stuck, the Getting unstuck appendix has a checklist that helps. The Glossary explains vocabulary; Python words will start showing up there as we encounter them.

Welcome to typing. Let's go.

Session 1: Welcome to Python — typing instead of dragging

Phase 2 — Python with Turtle · Session 1 of 8

What we're learning today

You spent eight weeks learning how to think like a programmer using Scratch. Today we move into a real programming language called Python — the kind of language used by people who write apps, games, and websites for a living. The blocks are gone. You'll be typing code instead of dragging it. By the end of class, you'll have typed your first Python program, watched a turtle draw on your screen, and made (and fixed!) your very first error message.

You'll need to remember from last time

• Sequences — code runs top to bottom. Order matters.
• The peanut butter rule — computers do exactly what you say, not what you mean. (This rule applies more to Python, not less. You'll see why.)
• That you finished Phase 1 and built your own game. You can do hard things.

Part A: Meet Thonny and your first turtle

Open Thonny on your computer. It's already installed — look for a friendly green icon (sometimes it looks like a snail). If you can't find it, ask your buddy or your instructor.

Thonny is what we'll use instead of Scratch. It's called an IDE (which stands for Integrated Development Environment, but nobody says that out loud). For now, it's the place where you'll type your Python code.

A tour of Thonny

When Thonny opens, you'll see two main areas:

• The editor (the top half, big white area). This is where you type your code.
• The shell (the bottom half). This is where Python tells you things — what your program printed, what error it ran into, things like that.

At the top there's a row of buttons. The one we care about today is the green Run button (or you can press the F5 key on your keyboard — same thing).

Type your first Python program

Click into the editor area at the top. Type this — exactly:

import turtle
t = turtle.Turtle()
t.forward(100)

Three lines. Pay attention to the symbols — the parentheses, the period after t, the period after turtle. Type them all. Type them carefully.

Now save your file. Press Ctrl-S (or File → Save). Thonny will ask where to save it and what to call it. Save it somewhere you'll remember (the desktop is fine for now), and call it first_turtle.py. The .py part is important — that's how your computer knows it's a Python file.

Now click the green Run button (or press F5).

A new window pops up — it's mostly white, with a small arrow-shape in the middle. That arrow is your turtle. Watch what happens: the turtle moves forward 100 pixels and stops.

Congratulations. You just wrote and ran a Python program.

What just happened

Let's break those three lines down:

• import turtle — this tells Python: "I want to use the turtle toolbox." Python comes with lots of toolboxes; you have to ask for the ones you want. We just asked for the one that does drawing with a turtle.
• t = turtle.Turtle() — this creates a new turtle and gives it the name t. (You can name it anything you want, but t is short and quick to type. Some people name it bob. Some name it george. The turtle doesn't care.)
• t.forward(100) — this tells the turtle named t to move forward by 100 pixels. The number 100 is called an argument — it's the information you're passing to the command.

Compare that to Scratch:

Same idea. Different way of telling the computer.

Make a typo on purpose

Now let's break it. Add a fourth line, but spell forward wrong:

import turtle
t = turtle.Turtle()
t.forward(100)
t.forwerd(100)

Click Run.

The turtle does the first forward. Then it stops, and the shell at the bottom turns red and shows you something like this:

AttributeError: 'Turtle' object has no attribute 'forwerd'

This is your first error message. Don't panic. Error messages are trying to help. Read it carefully.

Translation: "I tried to find a thing called forwerd for the turtle, but the turtle doesn't have anything called forwerd. You probably meant something else."

Fix the typo (change forwerd back to forward) and run again. The error goes away. The turtle moves twice.

The peanut butter rule strikes again. You meant forward. You typed forwerd. The computer doesn't know what you meant — it only knows what you wrote. Welcome to typing precision.

Draw a square

Now let's make the turtle draw a real shape. Replace your code with this:

import turtle
t = turtle.Turtle()
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)

Save (Ctrl-S). Run (F5).

The turtle walks forward 100, turns right 90 degrees, walks forward 100, turns again, four times. A square.

Look familiar? In Session 3 of Phase 1, you made the cat draw a square in Scratch with repeat 4. We don't have repeat yet in Python — that's next week. For now, four times by hand.

Checkpoint: You have a Python program saved as first_turtle.py that draws a square when you press Run. This is the natural stop point if class is cut short.

Part B: Colors, pen control, and shapes

Now let's make our drawings look better.

Colors

Add this line before you start drawing the square:

t.color("red")

Save and run. The square is red.

Try other colors: "blue", "green", "purple", "orange", "pink", "yellow", "black". Anything you'd guess, Python probably knows.

Thicker lines

Add this line too:

t.pensize(5)

Now the lines are five pixels thick instead of one. Try pensize(10) or pensize(20).

Lifting the pen

Sometimes you want to move the turtle without drawing. Use these:

• t.penup() — lift the pen, no more drawing
• t.pendown() — drop the pen, drawing again

Try this — two squares side by side:

import turtle
t = turtle.Turtle()
t.color("blue")
t.pensize(3)

t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)

t.penup()
t.forward(150)
t.pendown()

t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)

Two squares with a gap between them. The middle three lines (penup, forward 150, pendown) move the turtle without drawing.

Try this on your own

Pick one of these:

• Base goal: Draw a triangle. (A triangle is three sides. The turn at each corner is not 90 degrees — figure out what it should be. Hint: remember the polygon pattern from Session 3 of Phase 1.)
• Stretch: Draw your initials. Each letter as a few lines. Use penup() and pendown() to skip between letters.
• Extension: Draw a simple house. A square for the body, a triangle for the roof on top. Use color.

Wrap-up

Before we leave, let's share:

• What was different from Scratch?
• What was harder?
• What was easier?
• Did you get any error messages? What were they?

You did something today that's a big deal. You typed real Python code, ran it, made a typo, fixed it, and made the computer draw something. That's the entire programming workflow. Every programmer in the world does that exact loop, every day.

The hard part wasn't the typing. The hard part was getting used to being precise — every character matters, every parenthesis matters, every period matters. That precision will get easier fast.

If you missed this session

Open Thonny on your computer. Type these three lines exactly:

import turtle
t = turtle.Turtle()
t.forward(100)

Save the file as first_turtle.py. Click the green Run button or press F5. A window opens; the turtle moves.

Now extend it to draw a square. You'll need four t.forward(100) lines and four t.right(90) lines, alternating.

Then add t.color("red") and t.pensize(3) near the top to make the square colorful and thick. Save, run.

About 30 minutes of work. If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Try t.left(90) instead of t.right(90) and see what happens.
• Try t.backward(50) to walk the turtle backward.
• Try t.shape("turtle") (right after the t = ... line). The arrow becomes an actual little turtle shape. Then try "square", "circle", "triangle", "arrow".
• Try t.speed(1) (slow) or t.speed(10) (fast). Where does the speed matter? Where doesn't it?

What's next

Next week we'll learn about all the things the turtle can do — moving in different ways, going to specific positions, drawing patterns. By the end of next week's class, your drawings will look way fancier.

Session 2: Telling the turtle what to do

Phase 2 — Python with Turtle · Session 2 of 8

What we're learning today

Last week you typed your first Python code and made a turtle draw a square. Today we'll learn more things the turtle can do — jump to specific spots, face specific directions, draw circles, and even write text. By the end, you'll be able to draw a small scene with multiple parts: a sun, a house, a tree.

You'll need to remember from last time

• Open Thonny, type code in the editor, save with a .py extension, click Run (or press F5).
• Every Python turtle program starts with import turtle and t = turtle.Turtle().
• t.forward(N), t.right(N), t.left(N) for movement.
• t.color("red") and t.pensize(N) for style.
• t.penup() and t.pendown() for skipping without drawing.
• Sequences run top to bottom. Order matters in Python just like it did in Scratch.

Part A: More ways to tell the turtle what to do

Open Thonny, start a new file, and save it as scene.py. Type the standard opening:

import turtle
t = turtle.Turtle()

You'll add to it.

Jumping to a specific spot: goto

In Scratch, you used go to x: 0 y: 0 to send a sprite to a specific position. Python turtle has the same idea. The stage has a coordinate system: the middle is (0, 0), x goes right (positive) and left (negative), y goes up (positive) and down (negative).

Add this to your file:

t.penup()
t.goto(100, 50)
t.pendown()
t.forward(50)

Save. Run.

The turtle lifts its pen, jumps to the point (100, 50), drops the pen, and walks 50 forward from there.

You'll use goto constantly when you have multiple things to draw at different positions. Lift the pen, jump, drop the pen, draw.

Facing a specific direction: setheading

After goto, your turtle is somewhere, but which way is it facing? It's facing wherever it was facing before. That's often not what you want.

setheading makes the turtle face a specific direction:

• t.setheading(0) — face right (east)
• t.setheading(90) — face up (north)
• t.setheading(180) — face left (west)
• t.setheading(270) — face down (south)

So if you want to draw something that points up, you do:

t.penup()
t.goto(0, 0)
t.setheading(90)   # face up
t.pendown()
t.forward(80)      # draw an upward line

Use goto and setheading together when you need to start drawing in a known place at a known angle. Most multi-part drawings need both.

Circles

The turtle can also draw circles. Add this:

t.penup()
t.goto(-150, 100)
t.pendown()
t.color("yellow")
t.pensize(3)
t.circle(40)

Save. Run. A yellow circle of radius 40 appears in the upper-left area.

t.circle(40) draws a complete circle. The circle starts where the turtle currently is, and the turtle ends up back at that same spot when the circle is done.

You can also draw a partial circle by giving a second argument — how many degrees of arc to draw. t.circle(40, 180) draws a half-circle.

Writing text

The turtle can write text too. Add:

t.penup()
t.goto(0, 150)
t.pendown()
t.color("black")
t.write("My Scene", font=("Arial", 20, "normal"))

Save. Run. The text "My Scene" appears at the top of your window.

The font=("Arial", 20, "normal") part says what font and size to use. Don't worry about the syntax for now — just know you can change 20 to make the text bigger or smaller.

Build a scene together

Let's combine everything into a small scene. Start fresh — delete your code and type this:

import turtle
t = turtle.Turtle()

# the sun
t.penup()
t.goto(150, 100)
t.pendown()
t.color("yellow")
t.pensize(2)
t.circle(30)

# the house body (a square)
t.penup()
t.goto(-50, -50)
t.setheading(0)
t.pendown()
t.color("brown")
t.pensize(3)
t.forward(100)
t.left(90)
t.forward(100)
t.left(90)
t.forward(100)
t.left(90)
t.forward(100)
t.left(90)

Save. Run.

You should see a yellow sun in the upper right and a brown square (house) below it.

Notice the lines starting with # — those are comments. Anything after a # on a line is ignored by Python. Comments are how you leave notes for yourself (or other readers) explaining what each part of your code does. We'll use them more as our programs get bigger.

Checkpoint: You have a scene with at least two distinct elements (a sun and a house, or similar) drawn at different positions on the stage. This is the natural stop point if class is cut short.

Part B: Make it your scene

Now make this scene yours. The base goal is small; the stretch adds to it; the extension lets your imagination loose.

Base goal

Add a third element to your scene. Pick one:

• A roof on top of the house. (Triangle. Use goto to position the turtle at one corner, setheading to face the right way, then three forward/left pairs to draw the triangle. Don't forget the third turn at the end so the turtle's heading is predictable for whatever comes next.)
• A tree. A brown rectangle for the trunk, a green circle for the leaves on top.
• A second sun of a different color, in another corner.
• A title. Use t.write() to put your name or a title at the top of the scene.

Stretch

Add two more elements, of any kind. Mountains in the background. A second house. A road. A door on the existing house. Something that makes the scene feel like a place.

Start using comments (# something) to label what each part of your code is. It'll help you find things when the program gets longer.

Extension

Tell a tiny visual story. Add elements that suggest something is happening — a second person/animal, a path, smoke from the house's chimney, weather (clouds, rain, sun rays). Use as many turtle commands as you can.

Some commands you haven't formally seen but might want:

• t.circle(radius, extent) — partial circle
• t.shape("turtle") — make the cursor look like a little turtle
• t.speed(0) — turn the turtle drawing animation off (way faster)
• t.hideturtle() — hide the cursor entirely after drawing

Try them. The "If you finish early, just try things and see what happens" energy is exactly the right mindset.

Wrap-up

Before we leave, share with the room:

• What's in your scene?
• What was the trickiest part to position correctly?
• Did anyone discover a turtle command we didn't talk about?

You did something interesting today: you used multiple parts of your code to build one thing. The sun, the house, the tree — each a separate sequence of commands, all together making one drawing. That's how every real program works. Big programs are made of small pieces, each doing one thing.

Your scene is also probably long now — maybe 40 or 50 lines. Some of those lines repeat. Like the four pairs of forward(100) / left(90) to draw the square. Wouldn't it be great if you could say "draw a square" instead of typing those eight lines?

You can. That's next week.

If you missed this session

Open Thonny and start a new file. Save it as scene.py. Then:

1. Build the standard opening (import turtle and t = turtle.Turtle()).
2. Practice with goto: t.penup(), t.goto(100, 50), t.pendown(), t.forward(50). Run and see the turtle jump.
3. Practice with setheading: t.setheading(90), t.forward(50). The turtle now draws a line going up.
4. Practice with circle: t.color("yellow"), t.circle(40). The turtle draws a yellow circle.
5. Now build the scene from Part A above (sun + house). Then add one more element (Part B base).

About 30-40 minutes of work. If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Use t.fillcolor("red") and surround a shape with t.begin_fill() / t.end_fill() to fill it with color, not just outline.
• Use t.bgcolor("skyblue") to set the background color of the whole window.
• Use multiple turtles. After import turtle, do t = turtle.Turtle() and s = turtle.Turtle(). Now you have two turtles you can control independently. (Hint: this gets way more useful when we have loops next week.)

What's next

Next week we finally get loops in Python. Remember when you typed eight lines to draw a square last week, and your house this week? Next week you'll do it in three. By the end of class, you'll be drawing patterns that would take hundreds of lines by hand.

Session 3: Loops in Python — for and range

Phase 2 — Python with Turtle · Session 3 of 8

What we're learning today

Last week your code was getting long and repetitive — eight lines to draw a square, lots of similar lines for the scene. Today that's about to change. We'll learn the Python version of Scratch's repeat block, called a for loop. By the end of class, you'll draw a square in three lines instead of eight, and you'll be making patterns that would take hundreds of lines without loops.

You'll need to remember from last time

• Open Thonny, type code, save with .py, click Run.
• Every program starts with import turtle and t = turtle.Turtle().
• t.forward(N), t.right(N), t.left(N), t.color(), t.pensize().
• # starts a comment. Everything after it on the line is ignored.
• Loops from Scratch (repeat 4, forever). Same idea, new syntax.

Part A: The for loop

Open Thonny and start a new file. Save it as loops.py.

The square, the long way

Let's start by typing the square the way we did in Session 1:

import turtle
t = turtle.Turtle()

t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)
t.forward(100)
t.right(90)

Run it. A square. Eight lines.

Now look at those eight lines. Two lines repeated four times. That's exactly what a loop is for: doing the same thing N times without writing it N times.

The square, the loop way

Replace your eight lines with this:

import turtle
t = turtle.Turtle()

for i in range(4):
    t.forward(100)
    t.right(90)

Run it. Same square. Three lines instead of eight.

Let's break down what's happening:

• for i in range(4): — this means "do the next part 4 times." The range(4) produces a sequence of numbers from 0 to 3 (which is four numbers — Python starts counting at 0, not 1).
• i is the loop variable. Each time through the loop, i takes the next value from the sequence (0, then 1, then 2, then 3). We don't have to use i in this loop — but the syntax requires we name it. Most programmers use i by default.
• The colon at the end of the for line is required. Don't forget it.
• The lines underneath the for are indented — pushed in by four spaces. That's how Python knows they're part of the loop.

Indentation matters in Python

This is the big new thing about Python that didn't exist in Scratch. Indentation is part of the grammar.

In Scratch, you snapped blocks inside the repeat block's mouth. Python uses indentation instead. Lines that are indented under for i in range(N): are inside the loop. Lines that are not indented are outside the loop.

Try this — change the file so the second line isn't indented:

for i in range(4):
    t.forward(100)
t.right(90)

Now run it. The turtle moves forward 4 times in a straight line, then turns once. That's because only t.forward(100) is inside the loop. The t.right(90) is outside — it runs once, after the loop is done.

Indentation isn't decoration. It's part of what your program does. Be careful with it.

Good news: Thonny indents for you. When you type for ... : and press Enter, Thonny moves your cursor in 4 spaces automatically. Trust it.

Heads up: If you ever copy-paste code from somewhere, the indentation may not match. Mixed tabs and spaces is a common cause of confusing errors. If your code looks right but won't run, check the indentation by clicking each line and looking at the cursor position.

Try other shapes

Now try changing the loop count and the turn angle:

for i in range(3):
    t.forward(100)
    t.right(120)

Run it. A triangle.

Try range(5) and t.right(72). A pentagon.

Try range(6) and t.right(60). A hexagon.

You probably noticed: number-of-sides times turn-angle always equals 360. Same pattern as Phase 1 Session 3. Loops just made it way easier to test.

Checkpoint: You've replaced a manually-typed shape with a for loop, and you've used range(N) with a different number to draw at least one different shape (triangle, pentagon, etc.). This is the natural stop point if class is cut short.

Part B: Patterns that loops make easy

Now we'll do things that would have been ridiculous to type by hand.

A spiral

Start a new file. Save it as spiral.py. Type:

import turtle
t = turtle.Turtle()
t.speed(0)
t.color("blue")

for i in range(50):
    t.forward(i * 2)
    t.right(15)

Run it. A blue spiral that grows outward.

Look at what's happening: each time through the loop, i is different (0, 1, 2, 3, ... 49). And i * 2 (i times 2) is the distance the turtle walks. So the first time the turtle walks 0 steps, then 2, then 4, then 6... longer and longer. Combined with a 15-degree turn each time, it spirals.

This is the first time we've actually used the loop variable i for something. It's not just a counter — it's a value we can compute with. Variables are next week's lesson, so don't worry about the math yet — just notice that i does something.

t.speed(0) makes the turtle draw without animation (instant). On a long loop like this, the animation would take forever.

Try the base goal

Pick one:

• A colorful shape: Use a loop to draw a many-sided shape (like a 12-sided dodecagon, with range(12) and t.right(30)). Make it any color you want.
• A row of squares: Use a loop to draw 5 squares in a row, each one a small distance apart. (Hint: inside the loop, draw a square the long way — without a loop — then move the turtle to the next position.)

Stretch — nested loops

You can put a loop inside another loop. The inside loop runs all the way through, then the outside loop moves to its next iteration, then the inside loop runs all the way through again, and so on.

Try this — the flower of squares from Phase 1:

import turtle
t = turtle.Turtle()
t.speed(0)
t.color("purple")

for i in range(12):
    for j in range(4):
        t.forward(50)
        t.right(90)
    t.right(30)

Run it. A flower-shaped pattern made of 12 rotated squares.

The outer loop runs 12 times. Each time, the inner loop draws a square (4 sides), and then the outer loop turns 30 degrees. 12 squares × 30 degrees = 360 degrees, so they go all the way around.

Notice: the inner loop's body is indented twice (8 spaces from the left). Indentation level says how nested you are. The t.right(30) is indented once (4 spaces) because it's inside the outer loop but outside the inner loop.

This is genuinely confusing the first time. Read it carefully. Look at the indentation. Run it. Change the numbers and see what changes.

Extension

Make a colorful spiral that changes color as it grows. Add this to the spiral:

import turtle
t = turtle.Turtle()
t.speed(0)

colors = ["red", "orange", "yellow", "green", "blue", "purple"]

for i in range(60):
    t.color(colors[i % 6])
    t.forward(i * 2)
    t.right(15)

The colors[i % 6] part picks a color from the list based on which iteration we're in. The % operator gives the remainder when dividing — so i % 6 cycles through 0, 1, 2, 3, 4, 5, 0, 1, 2, 3... and that picks the colors in order, repeating.

If that's confusing right now, that's fine. Just type it and run it. Lists, indexing, and the % operator are things we'll cover properly in later sessions. For now, enjoy the rainbow.

Wrap-up

Before we leave, share with the room:

• What was the most-sides shape anyone drew?
• Did anyone try the nested-loops flower? What did it look like?
• Did anyone get a confusing indentation error? What fixed it?

You did something today that genuinely changes what you can build. Loops are how programmers make patterns, animations, and anything that involves "do this many times." From here on out, you'll use them constantly.

You also met indentation as a real grammar rule. That's the single weirdest thing about Python compared to most other programming languages. After a couple of sessions it'll feel normal — for now, just remember: indented = inside, not indented = outside.

If you missed this session

Open Thonny and start a new file. Save it as loops.py. Then:

1. Build a for loop that draws a square: ```python import turtle t = turtle.Turtle()

for i in range(4): t.forward(100) t.right(90) ``` Save, run. Watch the square draw.

2. Change range(4) and t.right(90) to draw a triangle (3 sides, 120 degrees) and a pentagon (5 sides, 72 degrees).

3. Try the spiral from Part B above.

About 30 minutes. Pay attention to indentation — the lines inside the loop need to be pushed in by 4 spaces (Thonny does this for you when you press Enter after the colon).

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Try range(N) with a different starting number: range(5, 15) produces 5 through 14. range(0, 20, 2) produces 0, 2, 4, 6, ..., 18 (counts by twos).
• Try a for i in range(360) loop where the turtle moves 1 step and turns 1 degree each iteration. What shape does that draw?
• Try multiple loops in one program. Draw five different shapes, one after another, with penup / goto between them to space them out.

What's next

Next week we'll learn about functions — how to take a chunk of code (like "draw a square") and give it a name, so you can just say draw_square() instead of writing the whole loop every time. It's the biggest new idea in Phase 2.

Session 4: Functions — making your own commands

Phase 2 — Python with Turtle · Session 4 of 8

What we're learning today

Today is the biggest new idea of Phase 2. You'll learn how to take a chunk of code and give it a name — so that instead of copying the same code over and over, you just call it by name. A named chunk of code is called a function, and they're how real programs get built. By the end of class, you'll have written your own draw_square and draw_house commands and used them to build a tiny neighborhood.

You'll need to remember from last time

• for i in range(N): — runs the indented body N times.
• Indentation matters. Lines indented under a for are inside the loop.
• t.color(...), t.pensize(...), t.penup(), t.pendown(), t.goto(x, y), t.setheading(angle).

Part A: Define your own command

Open Thonny and start a new file. Save it as functions.py.

The motivation

Suppose you want to draw three squares at three different spots on the stage. With what you know so far, you'd write the same loop three times, with goto calls between them:

import turtle
t = turtle.Turtle()

# square 1
for i in range(4):
    t.forward(60)
    t.right(90)

t.penup()
t.goto(-100, 0)
t.pendown()

# square 2
for i in range(4):
    t.forward(60)
    t.right(90)

t.penup()
t.goto(100, 0)
t.pendown()

# square 3
for i in range(4):
    t.forward(60)
    t.right(90)

Three squares. Lots of typing. The same loop, copied three times. We just learned loops to avoid copying things — and now we're copying things again.

There's a better way.

Functions: chunks of code with names

A function is a piece of code that you give a name to. Then, later, you can use that name like a command — and Python runs the chunk every time you call it.

Here's the syntax:

def draw_square():
    for i in range(4):
        t.forward(60)
        t.right(90)

Let's break it down:

• def — the keyword that starts a function definition. (It's short for "define.")
• draw_square — the name you're giving this function. You can call it almost anything, but the convention is lowercase with underscores, and the name should describe what it does.
• () — the parentheses are required (we'll put things in them in a minute).
• : — the colon, just like a for loop.
• The next lines are indented — pushed in by 4 spaces. Same rule as loops. The indented lines are the function's body.

Notice: typing def draw_square(): doesn't do anything. It defines the function. The turtle hasn't drawn anything yet. To use the function, you have to call it:

draw_square()

That's the call. The parentheses again — this time empty, because we're not passing any information yet.

Now the full program:

import turtle
t = turtle.Turtle()

def draw_square():
    for i in range(4):
        t.forward(60)
        t.right(90)

draw_square()

Save. Run. The turtle draws a square.

So far this is just one square — the same as before. But watch what happens when we want three:

import turtle
t = turtle.Turtle()

def draw_square():
    for i in range(4):
        t.forward(60)
        t.right(90)

draw_square()

t.penup()
t.goto(-100, 0)
t.pendown()
draw_square()

t.penup()
t.goto(100, 0)
t.pendown()
draw_square()

Three squares, but only one copy of the actual square-drawing code. The function draw_square() got called three times. If we ever wanted to change how the squares are drawn — say, to use a different color or a thicker pen — we'd change it in one place, not three.

This is one of the most powerful ideas in all of programming: write something once, use it many times.

Functions with parameters

Right now draw_square() always draws a square of size 60. What if we want different sizes?

We can give the function a parameter — a piece of information the function needs in order to do its job. For us, the size:

def draw_square(size):
    for i in range(4):
        t.forward(size)
        t.right(90)

Look at the differences:

• def draw_square(size): — the parameter size goes in the parentheses.
• t.forward(size) — instead of always 60, we use whatever size was passed in.

To call it, you put the size in the parentheses:

draw_square(50)
draw_square(100)
draw_square(75)

Each call draws a different-sized square — the same function, but with different values for size.

Build the full program and try it:

import turtle
t = turtle.Turtle()

def draw_square(size):
    for i in range(4):
        t.forward(size)
        t.right(90)

draw_square(40)
t.penup()
t.goto(-100, 0)
t.pendown()
draw_square(80)
t.penup()
t.goto(100, 0)
t.pendown()
draw_square(60)

Three squares, three different sizes, all drawn by the same function.

Checkpoint: You've defined a function that takes a parameter and called it more than once with different values. This is the natural stop point if class is cut short.

Part B: Build a neighborhood

Now we'll do something fun: build a row of houses, each one drawn by a function.

A function for the house

A house is just a square (the body) with a triangle on top (the roof). Build this in your file:

def draw_house(size):
    # the body — a square
    for i in range(4):
        t.forward(size)
        t.left(90)

    # move up to the top of the square
    t.left(90)
    t.forward(size)
    t.right(90)

    # the roof — a triangle
    for i in range(3):
        t.forward(size)
        t.left(120)

    # come back down
    t.right(90)
    t.forward(size)
    t.left(90)

A few things to notice:

• This function is longer than draw_square. Functions can be as long as they need to be.
• Inside it, we use two for loops (one for the square, one for the triangle). Functions can have all the same constructs any other Python code can.
• The t.left(90) / t.forward(size) / t.right(90) block in the middle is moving the turtle to where the triangle should start, without changing the overall direction it's facing. Spatial reasoning is part of functions like this.
• The lines starting with # are comments — explaining what each section does. Useful in longer functions.

Build the row

Now use draw_house() to make a row of three houses:

import turtle
t = turtle.Turtle()

def draw_house(size):
    # ... (the function from above)

# draw three houses in a row
t.penup()
t.goto(-200, 0)
t.pendown()
draw_house(60)

t.penup()
t.goto(-50, 0)
t.pendown()
draw_house(60)

t.penup()
t.goto(100, 0)
t.pendown()
draw_house(60)

Save. Run. Three houses across the bottom of the stage.

This is the base goal. Three houses, drawn by your own function, called three times.

Stretch — different sizes and colors

Modify draw_house to also take a color:

def draw_house(size, color):
    t.color(color)
    # ... (the rest of the function)

Now you can have houses of different sizes and colors:

draw_house(50, "red")
# move
draw_house(80, "blue")
# move
draw_house(60, "green")

A function can take as many parameters as you want, separated by commas. Both inside the def and inside the call, the order matters — size is first, color is second, every time.

Extension — functions calling functions

Build smaller helper functions and have draw_house use them:

def draw_square(size):
    for i in range(4):
        t.forward(size)
        t.left(90)

def draw_triangle(size):
    for i in range(3):
        t.forward(size)
        t.left(120)

def draw_house(size):
    draw_square(size)
    # move to top of square
    t.left(90)
    t.forward(size)
    t.right(90)
    draw_triangle(size)
    # come back down
    t.right(90)
    t.forward(size)
    t.left(90)

Now draw_house is much shorter — it just calls the smaller functions. And draw_square and draw_triangle could be used on their own, too. This is how big programs get built: lots of small functions, each doing one thing well, calling each other.

Try it. Then build an even bigger function — draw_neighborhood() — that calls draw_house() three times with different positions and colors. Now you have:

• draw_square() and draw_triangle() — small building blocks
• draw_house() — uses the small ones
• draw_neighborhood() — uses draw_house() three times

Three layers of functions, each one calling the layer below it. Real programs are built like this.

Wrap-up

Before we leave, share with the room:

• What did you build with functions today?
• Did anyone try the functions-calling-functions extension?
• If you wanted to add a sun and moon to your scene, would you write draw_sun() and draw_moon() functions or copy code? (The right answer is: it depends on whether you want to draw more than one of them.)

You learned the single biggest idea in writing reusable code today. Once you can write functions, you can build programs out of building blocks instead of typing everything from scratch. Functions show up in every programming language — Python, the JavaScript you'll learn in Phase 7, even some of the spreadsheet formulas your parents probably use at work. The syntax varies; the idea is universal.

You also met parameters — the way functions take in information. Parameters are how you make one function work for many situations.

If you missed this session

Open Thonny and start a new file. Save it as functions.py. Then:

1. Build the basic draw_square() function: ```python import turtle t = turtle.Turtle()

def draw_square(): for i in range(4): t.forward(60) t.right(90)

draw_square() ``` Save, run. A square.

2. Modify it to take a size parameter, and call it multiple times with different sizes (with penup/goto between).

3. Build the draw_house(size) function from Part B and call it three times to make a row of houses.

About 40 minutes of work. Pay attention to indentation and to the parentheses (one set in the def, one set when you call).

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Default values: write a function as def draw_square(size=50): and you can call it as either draw_square() (uses 50) or draw_square(80) (uses 80). Useful for making functions easier to call.
• A function that draws a polygon of any number of sides: def draw_polygon(sides, length): using range(sides) and 360 / sides as the turn angle.
• A function that takes a color list and draws a row of squares in those colors: pass ["red", "blue", "green"] as a parameter and loop through it. (Lists are coming in a later phase, but curious students can try.)

What's next

Next week we'll learn about variables — how to give names to numbers and use them throughout your code. Combined with what you know now, variables let you build programs that change behavior based on values you set. The neighborhood gets even better.

Session 5: Variables and a little math

Phase 2 — Python with Turtle · Session 5 of 8

What we're learning today

You've actually been using variables since Session 3 (the i in for i in range(N):) and Session 4 (parameters in your functions). Today we'll name our own variables, do math with them, and use them to make drawings that grow, shift, and change. By the end of class, you'll have built a "tower of squares" that gets bigger as it goes up — driven entirely by a variable.

You'll need to remember from last time

• Functions — def name(parameter): to define, name(value) to call. The body is indented underneath.
• Loops — for i in range(N): runs the indented body N times.
• The peanut butter rule is still in effect.
• Variables in Scratch — the orange "Make a Variable" blocks, set score to 0 and change score by 1. Same idea today, different syntax.

Part A: Names for values

Open Thonny and start a new file. Save it as variables.py.

Make a variable

In Scratch, you made a variable by clicking "Make a Variable." In Python, you make a variable by writing its name and giving it a value:

size = 50

That's it. The variable size now holds the value 50. No button to click; no setup required. Just write the name and assign with =.

The = sign in Python isn't "equals" the way it is in math — it's "give the name on the left this value on the right." Some programmers read size = 50 out loud as "size gets fifty." That helps remember it's an action, not a fact.

Use the variable in turtle code:

import turtle
t = turtle.Turtle()

size = 50

t.forward(size)
t.right(90)
t.forward(size)
t.right(90)
t.forward(size)
t.right(90)
t.forward(size)
t.right(90)

Save. Run. A square of size 50.

Now change the variable to size = 100. Save. Run. A square of size 100.

This is the power of variables: you change one number at the top, and the entire program changes behavior. Imagine if your square's size appeared in 20 different places in your code — without variables you'd have to find and change every one.

Math with variables

Variables aren't just storage — they're values, so you can do math on them. Python knows the basic arithmetic operators:

You can use them with variables too:

size = 50
big_size = size * 2     # 100
small_size = size / 2   # 25.0
size_plus_ten = size + 10   # 60

Variables can hold the result of math. They can also use other variables in their math.

Changing a variable

You can change what a variable holds. Just assign a new value:

size = 50
print(size)   # prints 50

size = 100
print(size)   # prints 100

The most common pattern: change a variable based on its current value:

size = 50
size = size + 10   # now size is 60
size = size + 10   # now size is 70

This is the Python equivalent of Scratch's change size by 10. Read it as: "size gets the current size plus 10."

(There's a shorter way to write it: size += 10 does the same thing as size = size + 10. Either is fine. Use whichever you find clearer.)

Using a variable inside a loop

Now we put it together. Add this to your file:

import turtle
t = turtle.Turtle()

size = 30

for i in range(5):
    # draw a square of the current size
    for j in range(4):
        t.forward(size)
        t.right(90)
    # move up
    t.penup()
    t.right(90)
    t.forward(size)
    t.left(90)
    t.pendown()
    # grow the size for next time
    size = size + 15

Save. Run.

A tower of squares! Each one is bigger than the last because size increases by 15 each iteration of the outer loop.

The first square is 30. Then size becomes 45 — second square is 45. Then 60. Then 75. Then 90.

The variable lives across iterations. The loop and the variable work together to produce the growing pattern.

Checkpoint: You've built a drawing that uses a variable that changes inside a loop, and the visual output reflects the changing variable. This is the natural stop point if class is cut short.

Part B: A variable-driven drawing

Now build something more complex with variables.

Base goal — a fan of lines

Build a fan of 12 lines, all coming from the same starting point, each rotated a bit further than the last. The angle is the variable that changes:

import turtle
t = turtle.Turtle()
t.speed(0)

angle = 0

for i in range(12):
    t.setheading(angle)
    t.forward(100)
    # come back to the start
    t.penup()
    t.backward(100)
    t.pendown()
    # rotate for next line
    angle = angle + 30

Save. Run. A fan of 12 lines spreading out in a half-circle.

Notice: setheading(angle) uses the variable to point the turtle in a specific direction each time. After drawing the line, we go back to the center, then increase angle by 30 for the next one. 12 lines × 30 degrees = 360, so they go all the way around.

Stretch — multi-color tower

Combine variables and color. Build a tower (like in Part A) but have the color change with each iteration:

import turtle
t = turtle.Turtle()
t.speed(0)

size = 30
red_amount = 50

for i in range(8):
    # use the variables to set color and draw
    t.color((red_amount / 255, 0.5, 0.5))

    for j in range(4):
        t.forward(size)
        t.right(90)

    # move up
    t.penup()
    t.right(90)
    t.forward(size)
    t.left(90)
    t.pendown()

    # update variables
    size = size + 10
    red_amount = red_amount + 25

The t.color((red_amount / 255, 0.5, 0.5)) line uses an RGB color (red, green, blue, each from 0 to 1). As red_amount grows, the red part of the color gets brighter — so each square in the tower has a slightly redder color than the one below it.

Don't worry about the RGB syntax for now — just notice that the color changes because the variable does.

If RGB feels too much, simpler version: change pensize based on i:

t.pensize(i + 1)

The first square uses pensize 1, the next 2, etc. Visible difference, simpler code.

Extension — a function

Wrap the tower in a function:

def draw_tower(start_size, count, growth):
    size = start_size
    for i in range(count):
        for j in range(4):
            t.forward(size)
            t.right(90)
        t.penup()
        t.right(90)
        t.forward(size)
        t.left(90)
        t.pendown()
        size = size + growth

draw_tower(20, 5, 10)
# move
t.penup()
t.forward(150)
t.pendown()
draw_tower(40, 3, 20)

Now you have a flexible tower-drawing function. You pass in the starting size, how many squares, and how much each one grows. Two different towers, drawn with one function. This combines Sessions 4 + 5 — functions with parameters, plus variables that change inside the function.

That's how real programs get built.

Wrap-up

Before we leave, share with the room:

• What's the highest size your tower got to?
• Did anyone try the multi-color version?
• For the kids who built the function: did you draw multiple towers? What were the parameter values?

You learned today how to store information in named places and do math with it. That's the foundation of every meaningful program — programs are mostly variables changing over time, with loops and conditionals deciding when and how.

Variables also gave you a new debugging tool: print(size) shows you the current value of size in the shell. When something's not behaving the way you expect, sprinkling some print() calls around your code is the most common way programmers figure out what's actually happening.

If you missed this session

Open Thonny and start a new file. Save it as variables.py. Then:

1. Make a variable: size = 50. Build a square that uses t.forward(size) and run it. Change size to 100, run again. Same code, different square.

2. Practice changing variables: size = size + 10. Try printing it after each change with print(size).

3. Build the tower from Part A — a for loop that draws a square of size size each iteration, then increases size by 15.

About 30-40 minutes. Watch your indentation; the inner square loop is indented twice (once for the outer loop, once for being the inner loop's body).

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Try negative growth: size = size - 10. Tower gets smaller going up. (When does it become invisible?)
• Use multiple variables in one drawing — x and y for position, size for shape. A tower that drifts sideways as it grows.
• Try print(size) inside the loop to watch the variable change in real time. The shell at the bottom of Thonny will show each value.
• Use variables for the loop counter math: for i in range(10): then t.forward(i * 5) makes a spiral that grows linearly. Combine with t.right(15) for the same spiral as Session 3.

What's next

Next week: conditionals. We'll bring back the if block, this time in Python. Combined with variables, conditionals let your programs decide what to do based on the values they're working with. After that, we have one more session of "putting it all together" before the milestone project.

Session 6: Conditionals — if in Python

Phase 2 — Python with Turtle · Session 6 of 8

What we're learning today

Today's the last "new syntax" session of Phase 2. We bring back the if block — but in Python instead of Scratch — and combine it with everything else you know to make programs that decide what to do based on the situation. Combined with variables, you can build programs that change behavior based on values you set. By the end of class, you'll have a function that draws colored shapes where the color depends on the size.

You'll need to remember from last time

• Variables — size = 50, size = size + 10.
• Math operators — +, -, *, /.
• Functions with parameters — def draw_square(size):.
• The if block from Scratch — "if something, then do this."
• Indentation matters — lines inside something are indented.

Part A: Making decisions in Python

Open Thonny and start a new file. Save it as decisions.py.

The if statement

Just like in Scratch, the if statement does something only when a condition is true. In Python, it looks like this:

size = 70

if size > 50:
    print("That's a big size!")

Walk through:

• if — the keyword that starts the conditional.
• size > 50 — the condition. This is a question Python can answer with True or False. Is size greater than 50? Yes or no?
• : — the colon (required, just like for and def).
• The next line is indented — it's the body that runs only if the condition is true.

Run it. Since size is 70, and 70 is greater than 50, Python prints "That's a big size!"

Now change size = 70 to size = 30. Run again.

This time nothing prints. The condition 30 > 50 is false, so Python skips the body of the if.

else for the other case

Often you want one thing to happen if the condition is true, and something else to happen if it's false. Use else:

size = 30

if size > 50:
    print("Big!")
else:
    print("Small!")

If size > 50, prints "Big!" Otherwise, prints "Small!"

else doesn't need a condition — it just runs whenever the if's condition was false.

The colon and indentation rules are the same. The body of else is indented underneath, just like if.

Comparison operators

The condition uses comparison operators to compare values. Python knows these:

The two important ones to be careful about:

• == for "is equal to" — two equals signs, not one. One equals sign (=) means assignment (giving a variable a value). Two equals signs (==) means comparison (asking if two things are equal). They look the same and they're not.
• != for "is not equal to" — the exclamation point means "not."

Try a few:

x = 10

if x == 10:
    print("x is exactly 10")

if x != 5:
    print("x is not 5")

if x >= 10:
    print("x is at least 10")

Run. All three prints happen, because x is 10.

Now change x = 5. Only the second prints (5 != 5 is false, so the third skips; 5 == 10 is false, so the first skips; but 5 != 5... actually that's also false. Wait — let me re-read. With x = 5: 5 != 5 is false. So... nothing prints. Try it.)

If you read those three carefully and predicted what would happen before you ran it — congratulations, you're starting to think like a programmer.

elif for multiple cases

Sometimes you want to check several conditions in order. elif (short for "else if") chains them together:

size = 30

if size > 100:
    print("Huge!")
elif size > 50:
    print("Big!")
elif size > 20:
    print("Medium!")
else:
    print("Tiny!")

Python checks each condition in order. The first one that's true, its body runs. If none are true, the else body runs.

With size = 30: 30 > 100 is false, 30 > 50 is false, 30 > 20 is true → prints "Medium!" The remaining elifs and else are skipped.

You can have as many elif lines as you want. The else at the end is optional.

Checkpoint: You've built an if/else (or if/elif/else) that makes decisions based on the value of a variable. This is the natural stop point if class is cut short.

Part B: Decisions in your drawings

Now we use conditionals where they really shine — making your drawings react to the values they're working with.

Base goal — colored squares by size

Build a function that draws a square, but colors it red if big and blue if small:

import turtle
t = turtle.Turtle()
t.speed(0)

def draw_colored_square(size):
    if size > 60:
        t.color("red")
    else:
        t.color("blue")

    for i in range(4):
        t.forward(size)
        t.right(90)

# draw a few squares of different sizes
draw_colored_square(40)
t.penup()
t.forward(60)
t.pendown()
draw_colored_square(80)
t.penup()
t.forward(100)
t.pendown()
draw_colored_square(50)

Save. Run.

You should see three squares: small blue, big red, medium blue. The function decides the color based on the size each time it's called.

This is small but powerful. You've combined functions (Session 4), variables (Session 5), and conditionals (today) into one little decision-making drawing function.

Stretch — three categories with elif

Add a third size category. Use elif:

def draw_colored_square(size):
    if size > 80:
        t.color("red")
    elif size > 40:
        t.color("orange")
    else:
        t.color("blue")

    for i in range(4):
        t.forward(size)
        t.right(90)

Now squares are red, orange, or blue depending on size. Try calling with various sizes (20, 50, 90, etc.) and see the colors.

Extension — a row of growing squares with conditional colors

Combine all of Phase 2 into one program: a loop that draws a growing row of squares, colored by size:

import turtle
t = turtle.Turtle()
t.speed(0)

def draw_colored_square(size):
    if size > 80:
        t.color("red")
    elif size > 40:
        t.color("orange")
    else:
        t.color("blue")

    for i in range(4):
        t.forward(size)
        t.right(90)

size = 10
for i in range(12):
    draw_colored_square(size)
    # move to next position
    t.penup()
    t.forward(size + 15)
    t.pendown()
    # grow
    size = size + 8

Save. Run.

A row of 12 squares, growing from small (size 10) to large (size 98). The colors transition: blue, blue, blue, blue, orange, orange, orange, orange, orange, red, red, red. The conditional inside the function picks the color; the loop drives the size forward.

This program uses every concept from Phase 2 so far: typing, sequences, loops, functions with parameters, variables, arithmetic, AND conditionals — all in one ~25-line program. You just built that.

Wrap-up

Before we leave, share with the room:

• What did your conditional decide on?
• For the kids who built the row of growing squares — does the color transition feel right, or would you tweak the thresholds?
• Did anyone try a condition with and or or? (Hint: those let you combine multiple conditions, like if size > 20 and size < 50:. We didn't formally cover them, but they work.)

You learned today how to make programs that decide — based on values, based on variables, based on what's happening. Combined with everything else, you now have the full toolbox that powers most of what computers do: store information (variables), repeat actions (loops), respond to inputs (events, which we'll see again in Pygame), bundle code (functions), and make decisions (conditionals).

That's basically what programming is. The rest is mostly applying these building blocks to specific problems.

If you missed this session

Open Thonny and start a new file. Save it as decisions.py. Then:

1. Build the basic if/else: ```python size = 30

if size > 50: print("Big!") else: print("Small!") `` Run. Then changesize = 70` and run again. Different output.

2. Try elif with three categories — small, medium, large.

3. Build the draw_colored_square(size) function from Part B above. Call it three times with different sizes.

About 30 minutes. Watch indentation — the body of if, elif, and else is indented underneath each one.

If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• Combine conditions with and: if size > 20 and size < 50:. Both conditions must be true.
• Combine with or: if size < 10 or size > 100:. Either condition can be true.
• Use not: if not size > 50: is the same as if size <= 50:. Sometimes one reads better than the other.
• Conditional inside a loop, deciding what to draw each iteration: python for i in range(8): if i < 4: # draw a triangle pass else: # draw a square pass Make a row that's half triangles, half squares.

What's next

Next week we put it all together — sequences, loops, functions, variables, conditionals — and build a creative drawing project that uses all of it. (Phase 1 also had events; Turtle doesn't really do events, so we save the event stuff for Phase 6 when we start writing real games in Pygame.) After next week is the milestone session, where you'll plan and build your own drawing project.

Session 7: Putting it together — a garden scene

Phase 2 — Python with Turtle · Session 7 of 8

What we're learning today

You now know everything in Phase 2: typing, turtle commands, loops, functions, variables, conditionals. Today we'll combine all of it into one creative drawing — a garden of flowers — where each flower is drawn by a function, multiple flowers are drawn by a loop, and the colors and sizes vary based on conditionals. By the end of class, you'll have a complete scene that's substantially more sophisticated than anything in Phase 1.

You'll need to remember from last time

Everything. No, really:

• Functions with parameters — def name(parameter):
• Variables and arithmetic — size = 50, size = size + 10
• For loops — for i in range(N):
• Conditionals — if/elif/else
• All your turtle commands — forward, right, left, color, pensize, penup, pendown, goto, setheading, circle, write

This is the test: can you put it all together? (Spoiler: yes.)

Part A: Build a flower function

Open Thonny and start a new file. Save it as garden.py.

Plan the flower

Before any code, think about what a flower looks like in Turtle terms. We need:

• A stem — a vertical line going up from the bottom.
• Petals at the top — several circles arranged in a ring.
• A position so we can put it somewhere on the stage.
• A color so different flowers can look different.
• A size so big and small flowers can coexist.

Position, color, size — those are parameters. The stem and petals are what the function does.

Build it

import turtle
t = turtle.Turtle()
t.speed(0)

def draw_flower(x, color, petal_size):
    # move to the bottom of the stem
    t.penup()
    t.goto(x, -100)
    t.pendown()

    # draw the stem
    t.color("green")
    t.pensize(3)
    t.setheading(90)   # face up
    t.forward(80)

    # draw the petals (8 circles in a ring)
    t.color(color)
    t.pensize(2)
    for i in range(8):
        t.circle(petal_size)
        t.right(45)

# draw one flower
draw_flower(0, "red", 15)

Save. Run.

A red flower in the middle of the stage. Stem going up, eight red circles around the top.

Walk through what's happening:

• draw_flower takes three parameters: x (where on the stage), color (petal color), petal_size (how big each petal circle is).
• The stem is always drawn green and 80 pixels tall.
• The petals loop runs 8 times. Each iteration draws a circle, then turns 45 degrees so the next circle starts in a different position. 8 × 45 = 360, so they go all the way around.

Try it with different parameters

Add three more flower calls:

draw_flower(-150, "yellow", 20)
draw_flower(150, "purple", 12)
draw_flower(-50, "pink", 18)

Run. Now you have four flowers across the stage, each different.

This is the same function called four times with four different sets of arguments. One function, multiple flowers. You've seen this pattern before in Session 4 — the power is the same; the visual is fancier.

Checkpoint: You have a draw_flower function and at least three flowers on the stage drawn by calling it. This is the natural stop point if class is cut short.

Part B: A garden with variation

Now we use loops + conditionals to make a bigger garden where the flowers vary in interesting ways.

Base goal — a loop-driven row

Use a for loop to draw a row of flowers across the stage. Pick a starting position, increment the x-coordinate each time:

import turtle
t = turtle.Turtle()
t.speed(0)

def draw_flower(x, color, petal_size):
    t.penup()
    t.goto(x, -100)
    t.pendown()
    t.color("green")
    t.pensize(3)
    t.setheading(90)
    t.forward(80)
    t.color(color)
    t.pensize(2)
    for i in range(8):
        t.circle(petal_size)
        t.right(45)

# draw a row of 5 flowers
x = -200
for i in range(5):
    draw_flower(x, "red", 15)
    x = x + 100

Run. Five red flowers in a row.

The variable x starts at -200 and increases by 100 each iteration. The loop runs 5 times; the x value drives where each flower appears.

Stretch — different colors per flower

Right now all five are red. Let's make each one a different color, using a conditional inside the loop to pick the color based on the iteration number:

x = -200
for i in range(5):
    if i == 0:
        color = "red"
    elif i == 1:
        color = "orange"
    elif i == 2:
        color = "yellow"
    elif i == 3:
        color = "purple"
    else:
        color = "pink"

    draw_flower(x, color, 15)
    x = x + 100

Now you have a rainbow of flowers. The conditional picks a color based on i, then draw_flower uses it.

(Yes, this is verbose. There's a better way using a list — but we haven't covered lists yet. We'll get there in Phase 3.)

Extension — a complete scene

Add more elements to make a real garden scene:

• A sun in the upper corner.
• Grass at the bottom (a horizontal green line).
• Sky by changing the background color.
• A title at the top using t.write().
• Variable petal sizes — make some flowers bigger than others using another conditional or by varying the parameter.

Here's a starting structure:

import turtle
t = turtle.Turtle()
t.speed(0)

# set the scene
t.bgcolor("skyblue")

def draw_flower(x, color, petal_size):
    # ... (same as before)

def draw_sun(x, y, size):
    t.penup()
    t.goto(x, y)
    t.pendown()
    t.color("yellow")
    t.pensize(2)
    t.circle(size)

def draw_grass(y):
    t.penup()
    t.goto(-240, y)
    t.pendown()
    t.color("green")
    t.pensize(8)
    t.forward(480)

# build the scene
draw_sun(180, 120, 40)
draw_grass(-100)

# row of flowers (with the conditional color picker from above)
x = -200
for i in range(5):
    if i == 0:
        color = "red"
    elif i == 1:
        color = "orange"
    elif i == 2:
        color = "yellow"
    elif i == 3:
        color = "purple"
    else:
        color = "pink"

    draw_flower(x, color, 15)
    x = x + 100

# title
t.penup()
t.goto(-100, 150)
t.pendown()
t.color("black")
t.write("My Garden", font=("Arial", 24, "normal"))

Save. Run.

A complete garden scene: blue sky, yellow sun, green grass, five colorful flowers in a row, and a title.

This program uses every concept from Phase 2: typing the code in Thonny, turtle commands, multiple sequences (each function is a sequence), three loops (the petals, the for-loop driving the row, plus you could argue more), three functions with parameters, two variables (x and color) that change inside the loop, and a conditional choosing the color.

You went from "just typed your first line of Python" to "writing a fifty-line program with multiple functions and a creative output" in seven weeks. That's a real arc.

Wrap-up

Before we leave, share with the room:

• What did your garden look like? Anyone do something unexpected?
• For the kids who built the full scene — was anything trickier than you expected?
• What would you do differently if you started over?

Important: start thinking about your milestone project for next week. You'll have one session — next week — to plan and build a Turtle drawing of your own design, then show it to the class. Some seed ideas:

• A landscape scene — mountains, trees, a river, a sunset.
• A fancy pattern — like a snowflake or a mandala (radial symmetry around a center point).
• An abstract drawing — colored shapes arranged for visual effect.
• A scene from somewhere you like — a beach, your room, a page from a comic.
• An animal built from circles and shapes.
• Your name in giant decorated letters.

Don't decide today. But come to next week's class with at least one idea you're excited about.

If you missed this session

Open Thonny and start a new file. Save it as garden.py. Then:

1. Build the draw_flower(x, color, petal_size) function from Part A. Call it once to draw a single flower.

2. Call it three or four more times with different positions, colors, and sizes.

3. Wrap the calls in a for loop driven by an x variable that starts at -200 and increases by 100 each iteration.

4. Add a conditional inside the loop to pick a different color for each flower (Part B stretch).

About 40-50 minutes. Pay attention to indentation — the loop body is indented once, the if/elif/else bodies inside the loop are indented twice.

If you get stuck, ask your buddy at the start of next class. And think about what you want to build for your own milestone project.

Stretch and extension ideas

• Replace the if/elif/else color-picker with a list. (We haven't formally taught lists, but a curious student can try: colors = ["red", "orange", "yellow", "purple", "pink"] and then color = colors[i] inside the loop. That replaces five if/elif lines with one.)
• Add variation in petal count. Some flowers have 8 petals; some have 6 or 12. Use a parameter for it.
• Build a 2D grid of flowers using a nested for loop (outer loop varies y, inner loop varies x). A whole field.
• Add clouds to the sky using ovals (or just multiple circles side by side).

What's next

Next week is your milestone project + demo day. You'll plan, build, and demo your own Turtle drawing — your design, your choices. Bring an idea (or two). After Phase 2, we move into Phase 3 — Python basics, where Python becomes more general: no more turtle, but lots more of what Python can do.

Session 8: Milestone project + demo day

Phase 2 — Python with Turtle · Session 8 of 8

What we're learning today

Today is your day. You'll plan, build, and demo a Turtle drawing of your own design — your idea, your code, your scene. By the end of class, you'll have shown your work to the room and finished Phase 2. There's no new programming concept this week; today is about putting your skills to use on something you chose.

You'll need to remember from last time

• Everything from Sessions 1-7. Functions, loops, variables, conditionals, all the turtle commands.
• The garden scene you built last week — proof you can make something substantial.
• The idea you (hopefully) brought with you today. (If not, Part A has a list to start from.)

Part A: Plan and start building

Today is structured tighter than Phase 1's milestone — we have one session for planning, building, and demoing — so we move quickly and you decide what's important.

The plan

Take a piece of paper or open a blank text file. Answer these four questions about your project. Keep it short — first answers are usually right:

1. What are you drawing? (One sentence. Examples: "A snowy mountain landscape." "My initials in giant decorated letters." "A snowflake pattern.")

2. What functions do you need? (Each function does one thing. Examples: draw_mountain(), draw_tree(), draw_letter_A(), draw_petal(). Brainstorm 2-5.)

3. What will vary? (What are the parameters? Position? Color? Size? List which functions need which parameters.)

4. What's the simplest version that's still cool? (If you only had 30 minutes to build, what would you do FIRST? What would you add LATER if there's time? This is the most important question.)

If you don't have an idea

Pick one and modify it slightly:

• A snowy mountain landscape — triangles for mountains, small circles for snow, a cabin or tree at the bottom.
• A snowflake — radial symmetry around a center point. Use a function to draw one "arm" and a loop to call it 6 times rotated.
• A name in giant letters — each letter is a function, drawn with forward / right / left / pen control.
• A field of flowers like last week, but bigger or with different flower types.
• An abstract pattern — shapes radiating from a center, spirals within spirals, anything geometric.
• A simple animal — a cat, a fish, a bird built from circles and lines.
• Your favorite emoji — recreated in turtle code. You'd be surprised what's possible.

Pick one. Spend two minutes deciding. Don't agonize — you can modify the idea while you build.

Show your instructor

When your plan is ready (about 10 minutes in), show it to your instructor. He'll either say "go build it" or ask one question that helps you tighten it up. Then start building.

Start building — the simplest version first

Look at your answer to question 4. Build that first. Get the simplest version working before adding anything fancy. Real programmers do this — get something runnable as fast as possible, then improve from there.

If you said "the simplest version is just one mountain" — build one mountain. Run it. See it. Then add a second one. Then snow. Then trees.

Don't try to type the whole project before testing. Build small. Test often. Add piece by piece.

When you get stuck

The same five steps as always:

1. Read your code carefully. Did you tell the computer the right thing?
2. Read the error message. Most Python errors point at the exact line.
3. Look at how you did something similar before. Last week's garden? Open it for reference.
4. Ask your buddy.
5. Ask your instructor.

The Getting unstuck appendix has more on this.

Checkpoint: You have a written plan with the four questions answered, your instructor has signed off, and you've started building the simplest version. This is the natural stop point if class is cut very short — but for today, we're going to keep going to the demo half.

Part B: Final polish, then demo

After the break, you have about 15 minutes to finish or polish, then we demo.

Polish (~10-15 min)

Be honest with yourself about what's done. Three things make a project ready to demo:

1. It runs. You can press the green flag and see something without an error.
2. It does what your plan said it would do — at least the simplest version (your answer to question 4).
3. You can explain how it works. Walk someone through the functions and what they each draw.

If your project doesn't meet those three, focus on getting it there before adding anything new. A working simple project is way better than a broken ambitious one.

Buddy test (~5 min)

Swap with your buddy. They run your project; you run theirs. Notice:

• Did it run?
• Did the visual surprise them in any way (good or bad)?
• Could they tell what each part of the drawing was?

Tell each other one thing you noticed.

Demos

Each of you demos for 3-5 minutes. Same format as Phase 1 demo day:

1. Show your drawing. Run it. Let the class see it appear.
2. Tell us about it. What were you trying to make? What functions did you write?
3. Tell us one thing that was hard. Honest, not bragging. Maybe the math on a turn angle. Maybe positioning a sprite correctly. Things that broke and how you fixed them.
4. Take one question. Someone asks something specific — "how did you make the snowflake?", "what made you pick those colors?" Answer as best you can.

When it's not your turn, watch carefully and have one specific question ready when called on. "I really liked X" is nice; "How did you make X?" is better.

After everyone demos

Your instructor will say a few specific things about each of your projects. Then we're done — Phase 2 is complete.

What you accomplished

• You built two programs from scratch in Python this phase: the garden last week, and your own project today. That's two more than you'd built before Phase 2.
• You learned functions — the most powerful tool for organizing code that we cover in the entire curriculum.
• You typed real Python code, made (and fixed) lots of error messages, and you kept going. That's what programming is.
• You shipped two milestone projects so far in your programming journey. The Phase 1 game; today's drawing. Most adults haven't shipped one creative project ever. You're at two.

What's next

Next week starts Phase 3 — Python basics. Real Python beyond the turtle.

What's different in Phase 3:

• No more turtle. The turtle was great as a bridge — visual, immediate. But real Python programs do all sorts of things that aren't drawing. We'll write programs that think with text, numbers, lists of things.
• Strings, lists, files. Programs that talk to you, ask questions, remember things across runs.
• Real-world projects. A number-guessing game. A text adventure. Something that reads a file (your favorite song lyrics, maybe?) and does something useful with it.
• The Thonny debugger. The single most useful Python tool you haven't met yet. It lets you watch your program run line by line and see exactly what's happening.

Bring your machine and your brain. We're going deeper.

If you missed this session

Two cases:

If you missed only the demo half: Show your project to your instructor at the start of next week's class. He'll give you the same kind of feedback the demo would have.

If you missed the whole session and don't have a finished project: No big deal. Pick one of the seed ideas above (or extend last week's garden), build it at home using everything you know, and bring it next week. Or: just join us in Phase 3 — what you've already built is plenty to be proud of.

Stretch and extension ideas

If you have time after the demos and want to keep going:

• Polish your project more. Add details, sounds, more variation.
• Build a second project of a different style. With everything you know now, the second one is faster than the first.
• Show your work to your family. They will be impressed.
• Save your project files. You'll want to look back at them in a year and be amazed at what you knew at this stage.

What's next

Phase 3 — Python without the turtle. See you there.

Phase 3 — Python basics

Phase 2 used the turtle to make typing Python feel friendly and visual. This phase is where Python becomes general-purpose — the language used by professionals to write everything from scripts that automate work, to data analysis, to web servers, to AI tools.

What this phase is

The biggest phase in the curriculum. Sixteen sessions on the core building blocks of Python: text, numbers, decisions, loops, functions, lists, dictionaries, files, and error handling. By the end, you'll be able to write small programs that talk to people, store information, read and write files, and handle mistakes gracefully.

We leave the turtle behind. No more drawings on a stage. Instead, your programs run in the shell at the bottom of Thonny — they print things, ask the user questions, and respond based on what they're told. Less visual, more flexible. Most software in the world works this way at its core.

What you'll learn

A lot of these sessions cover ideas you've already seen in Phase 1 (Scratch) or Phase 2 (Turtle) — variables, conditionals, loops, functions. What's new is how Python does each one in a text-based context, plus several genuinely new tools: lists, dictionaries, files, the debugger, and proper error handling.

What you'll build

Multiple working programs throughout the phase, not just one big project at the end:

• Session 1: a tiny program that asks for your name and greets you.
• Session 7: a number-guessing game. The computer thinks of a number; you have to guess it.
• Session 12: a hangman game. Real game logic, real word list, real win/lose conditions.
• Session 14: a text adventure or a CSV reader. Multi-room, multi-choice text-based game, OR a program that reads a real file (favorite quotes, sports stats, whatever interests you) and does something with it.
• Session 16: a milestone project of your own design. Free choice within "make something using Python that does something useful or fun."

What you'll need

Same machine as Phase 2 — Thonny is already installed; nothing new to install for Phase 3. The Python turtle library you used in Phase 2 is replaced with Python's built-in print, input, file I/O, and other tools — all of which come standard with Python.

If you want to work at home, the Installing on your own computer appendix has Thonny instructions.

How sessions work

Same shape as Phases 1 and 2:

• Part A introduces a new idea with a guided exercise. Stands alone if class gets cut short.
• Part B is open practice or a project that uses Part A. Often tiered (base / stretch / extension).
• Wrap-up — a few minutes of sharing what you did.

A note about the shell

Phase 2 had two windows: Thonny (where you typed code) and the turtle window (where drawings appeared). Phase 3 uses just Thonny. The shell at the bottom of the editor is where your program prints things and where you type answers when it asks.

The shell is also useful by itself — you can type one-line Python expressions there and press Enter to see what they do. We'll use it for quick experiments throughout the phase.

A note about errors

Phase 2 had typos and syntax errors. Phase 3 will have more of them — partly because the syntax is more varied, partly because your programs are doing more. The Reading error messages appendix gets fleshed out as Phase 3 progresses.

The single best advice: read the error message slowly. Python's errors are friendlier than they look once you get used to them.

Where to start

Session 1: Welcome to Python (without the turtle) opens with a callback to a moment from Session 1 of Phase 1. You might want to glance at the Phase 1 Welcome chapter before reading, just to remember.

When you're stuck, the Getting unstuck appendix has the checklist. The Glossary explains vocabulary. New terms get added as Phase 3 introduces them.

Welcome to general Python. Let's go.

Session 1: Welcome to Python (without the turtle)

Phase 3 — Python basics · Session 1 of 16

What we're learning today

Phase 2 used the turtle to give your code something visual to do. Phase 3 leaves the turtle behind. Today we'll learn the two most-used commands in all of Python: print (Python tells you something) and input (Python asks you something). By the end of class, you'll have written a program that talks to the person running it.

You'll need to remember from last time

• Thonny. Open the editor, type code, save with .py, click the green Run button.
• Variables. name = "Sam" puts the value "Sam" in a variable called name.
• The peanut butter rule. Still in effect. Maybe even more in effect today.
• You finished Phase 2. You wrote real Python code with functions, loops, conditionals, all of it. Today builds on that.

Part A: A familiar friend (and print)

You may notice Your instructor brought the bread back today. Loaf, peanut butter, jelly, knife, plate. The whole setup from Session 1 of Phase 1.

Same exercise: tell your instructor how to make a peanut butter and jelly sandwich, step by step. He'll do exactly what you say.

But notice: you're way better at this now. Eighteen weeks ago, the room couldn't even get past "open the peanut butter." Today, the instructions are tighter, more careful. Some of you are already saying things like "grab the handle of the knife between your thumb and forefinger" without being prompted.

That's not nothing. Programming has changed how you give instructions. You think about steps differently. You notice when something is ambiguous. That's a skill you'll have for the rest of your life.

Why we're doing it again now

For all of Phase 2, the turtle was your safety net. If your code was wrong, the visual feedback told you immediately — "the square's lopsided" or "the turtle went off-screen." Today the turtle goes away. We're using just text.

That means the peanut butter rule matters even more. With text, mistakes are quieter. A missing letter, a missing colon, a typo in a variable name — and your program either crashes or quietly does the wrong thing. There's no visual to clue you in.

Today you start writing programs that talk to people. People expect their programs to work. That puts more pressure on you to be precise. Welcome to real programming.

Hello, world

Open Thonny. Start a new file. Save it as hello.py.

Type just one line:

print("Hello, world!")

Save. Run.

Look at the shell at the bottom of Thonny. You should see:

Hello, world!

That's it. That's your first non-turtle Python program.

What's different from Phase 2:

• No import turtle. We're not using the turtle today.
• No t = turtle.Turtle(). No turtle.
• Output goes to the shell at the bottom, not to a separate drawing window.

Try a few more print calls:

print("Hello, world!")
print("My name is", "your name here")
print("Five plus three is", 5 + 3)
print("Three tens is", 10 * 3)

Save. Run.

Each print call shows up on its own line in the shell.

Notice that print can take multiple things separated by commas. Each thing gets printed with a space between. Numbers don't need quotes (they're values); text needs quotes (it's a string).

"Writing 'Hello, world!' as your first program is a tradition. Every programming language ever has a 'hello world' program. You just joined that tradition."

Checkpoint: You have a Python file that prints at least three different lines to the shell when you run it. This is the natural stop point if class is cut short.

Part B: Asking the user something

Now the other half — input. This is how a program asks the user a question and gets their answer.

Your first interactive program

Replace your code with this:

name = input("What's your name? ")
print("Hello, " + name + "!")

Save. Run.

Watch the shell. You'll see:

What's your name?

…and then nothing happens. The program is waiting for you.

Type your name and press Enter. Now:

What's your name? Sam
Hello, Sam!

Walk through what happened:

• input("What's your name? ") — printed the prompt, waited for the user to type and press Enter, then returned what the user typed.
• name = input(...) — saved what the user typed in a variable called name.
• print("Hello, " + name + "!") — used the variable in the output.

The + between strings is string concatenation — a fancy word for "stick them together." "Hello, " + "Sam" + "!" becomes "Hello, Sam!". Like joining links in a chain.

Multi-question version

Try this — a longer version that asks multiple things:

name = input("What's your name? ")
color = input("What's your favorite color? ")
food = input("What's your favorite food? ")

print("Nice to meet you, " + name + "!")
print("Did you know that " + color + " " + food + " is delicious?")

Run it. Type three answers. The program echoes back a sentence about you.

Yes, the sentences are absurd. That's the fun part.

Try this on your own

Pick one:

• Base goal: Build a multi-question program that asks at least four things and uses all the answers in some output. Make the questions whatever you want — favorite movie, favorite hymn, where you'd like to travel, what you ate for breakfast.

• Stretch: Use a conditional (callback to Phase 2 Session 6!) to react to one of the answers:

python color = input("What's your favorite color? ") if color == "blue": print("Great choice!") else: print("That's a fine color too, but blue is the best.")

Try this for one or two of your questions.

• Extension: Wrap a greeting in a function (callback to Phase 2 Session 4!):

```python def greet(name): print("Hello, " + name + "!") print("Welcome to Python.")

your_name = input("What's your name? ") greet(your_name) ```

Now you've combined input + functions + variables in one tiny program.

Wrap-up

Before we leave, share with the room:

• What questions did your program ask?
• Did anyone get a particularly weird sentence in their output?
• For the kids who did the conditional stretch — did the computer agree with your favorite color?

You learned today how to make programs talk to people. Every website that asks for a username, every game that asks "would you like to start a new game?", every spreadsheet that prompts "are you sure you want to delete?" — they're all doing what your program did today. Just at bigger scale, with prettier graphics. The core mechanic is the same: print a question, wait for input, do something with the answer.

The turtle was a fun way to learn. Text is how most software actually works under the hood.

If you missed this session

Open Thonny and start a new file. Save it as hello.py. Then:

1. Type print("Hello, world!"). Save. Run. Look at the shell at the bottom — your message appears.

2. Add a few more print lines with different text or simple math.

3. Now try input: python name = input("What's your name? ") print("Hi, " + name + "!") Save. Run. Type your name when prompted.

4. Build a multi-question version (the Part B base goal above).

About 30 minutes. If anything's confusing, ask your buddy at the start of next class.

Stretch and extension ideas

• The user can also enter numbers, but input() always returns a string even if they type a number. To do math with the number, you need to convert it: age = int(input("How old are you? ")). We'll talk about why next week — try it for now.
• input() will also work with no prompt: answer = input() — but it's confusing for the user (they don't know what to type). Always pass a prompt.
• print with no arguments — print() — outputs a blank line. Useful for spacing your output.

What's next

Next week we formalize variables and types — what's the difference between 42, 42.0, and "42", and why does it matter? (Spoiler: this is the answer to "why does input() give me a string when I typed a number.")

Session 2: Variables and types

Phase 3 — Python basics · Session 2 of 16

What we're learning today

You've been using variables for a while now (Phase 1 Session 6, Phase 2 Session 5). Today we get specific about what kinds of values variables can hold — numbers, decimals, text, and what happens when you mix them up. By the end of class, you'll have written a program that does math with answers from the user, and you'll know why "5" + "3" is "53" instead of 8.

You'll need to remember from last time

• print(...) — Python tells you something.
• input(...) — Python asks you something. Returns whatever the user typed.
• + — sticks two strings together (concatenation).
• Variables — name = "Sam".

Part A: Three kinds of values

Open Thonny and start a new file. Save it as types.py.

A type is a category of value. Python has lots of types, but three matter for almost everything you'll do:

Notice that 5 and 5.0 look almost the same but are different types — one is an int, one is a float. And "42" (with quotes) is a string even though it looks like a number.

See the type with type()

Python has a built-in function called type() that tells you what type a value is. Try this:

print(type(5))
print(type(5.0))
print(type("Hello"))
print(type("5"))

Save. Run.

The shell shows:

<class 'int'>
<class 'float'>
<class 'str'>
<class 'str'>

Notice the last two: 5.0 is a float, but "5.0" (with quotes) is a string. The quotes change everything.

Why types matter

Try this:

print(5 + 3)
print("5" + "3")

Run. The shell shows:

8
53

Two completely different answers. Same-looking values; different types; different behavior.

• 5 + 3 is number addition. Five plus three is eight.
• "5" + "3" is string concatenation. "5" stuck together with "3" is "53".

Python + does different things depending on what it's between. With numbers, math. With strings, sticking together.

This matters because input() always returns a string — even if the user typed a number. Try:

age = input("How old are you? ")
print(type(age))
print(age + 1)

Save. Run. Type your age and press Enter.

You get an error:

TypeError: can only concatenate str (not "int") to str

Translation: "I can't add a number to a string. They're different types."

The fix: convert the string to a number before doing math with it.

Type conversion

Python has functions for converting between types:

Fix the previous program:

age = int(input("How old are you? "))
print(type(age))
print(age + 1)

The int(input(...)) does two things: gets the user's input (as a string), then converts it to an integer.

Save. Run. Type your age. Now you see:

<class 'int'>
[your age plus 1]

The error is gone because age is now an int, and you can add 1 to an int.

This is one of the most common patterns in Python: convert input to the type you actually want to work with.

One more conversion

You might also need str() to go the other direction. Try this without conversion:

score = 100
print("Your score is " + score + " points!")

Run. Error: TypeError: can only concatenate str (not "int").

Fix it with str():

score = 100
print("Your score is " + str(score) + " points!")

Now the int 100 becomes the string "100", which can be concatenated with the rest of the message.

(There's a much nicer way to do this in Python called f-strings — coming next week.)

Checkpoint: You've used type() to check the type of at least three different values, you've seen the difference between 5 + 3 and "5" + "3", and you've used int() to convert input to a number for math. This is the natural stop point if class is cut short.

Part B: A real program with math

Now let's build something useful with input + types.

Base goal — age in years

Build this:

print("Welcome to the Age Calculator!")
age = int(input("How old are you? "))
years = int(input("How many years from now? "))

future_age = age + years
print("In " + str(years) + " years, you'll be " + str(future_age) + ".")

Run. Type your age (e.g., 12). Type a number of years (e.g., 8). The shell tells you what age you'll be then.

Walk through what's new:

• Two int(input(...)) calls to get two numbers.
• Math on variables: age + years adds them.
• str() on the way out so we can concatenate the numbers into the output string.

Tedious but it works. You'll see why f-strings are nicer next week.

Stretch — decimals

What if you want fractional answers? Use float:

print("Average calculator!")
a = float(input("First number: "))
b = float(input("Second number: "))
c = float(input("Third number: "))

average = (a + b + c) / 3
print("The average is " + str(average))

Now the user can type decimals (like 4.5 or 7.25) and the result handles fractional averages.

The parentheses in (a + b + c) / 3 matter — they make sure the addition happens first, then the division. Math order of operations applies in Python just like math class.

Extension — multi-step calculator

Build a tip calculator. Or a "how many minutes until..." program. Or "convert miles to feet." Or anything that asks the user for numbers, does some math, and reports the result.

For example, a savings calculator:

print("Savings Calculator")
weekly_save = float(input("How much do you save each week? $"))
weeks = int(input("How many weeks? "))

total = weekly_save * weeks
print("In " + str(weeks) + " weeks, you'll save $" + str(total))

Or a unit converter:

miles = float(input("How many miles? "))
feet = miles * 5280
print(str(miles) + " miles is " + str(feet) + " feet.")

Pick something you'd want to know an answer to, and write the program to compute it.

Wrap-up

Before we leave, share with the room:

• What did your calculator compute?
• Did anyone hit a TypeError they had to fix?
• For the kids who built the savings or unit conversion — does the answer look right?

You learned today how Python tells different kinds of values apart, and how to convert between them. Types are one of the fundamental ideas in programming. Every value has a type. Operations behave differently depending on type. Errors happen when types don't match.

In Phase 2 you got away with not thinking about types because turtle commands took numbers and you typed numbers. Now that input() is in the mix, type conversion becomes part of every interactive program.

If you missed this session

Open Thonny and start a new file. Save as types.py. Then:

1. Try print(type(5)), print(type(5.0)), print(type("hi")). See the three types: int, float, str.

2. Try print(5 + 3) and print("5" + "3"). Notice the different answers.

3. Build the age calculator from Part B base: python age = int(input("How old are you? ")) years = int(input("How many years from now? ")) future_age = age + years print("In " + str(years) + " years, you'll be " + str(future_age) + ".")

4. Customize: build a calculator that asks for numbers and reports something useful (savings, conversion, average).

About 30 minutes. If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• What does int("5.7") do? What does int(5.7) do? Try both and see.
• What does float("hello") do? Run it and read the error message.
• What does str(5) + str(3) return? Why?
• What does int("5") + int("3") return? Why?
• Try 5 + 5.0 — what type is the result? (Hint: it'll be a float. When you mix int and float, Python promotes to float.)

What's next

Next week we dig deeper into strings — text is the most common kind of data in real programs (names, addresses, sentences, file contents). We'll learn how to slice strings, search them, change their case, and — most importantly — use f-strings to format text without all the + str(...) + mess from today.

Session 3: Strings — text in Python

Phase 3 — Python basics · Session 3 of 16

What we're learning today

Last week's age calculator had a bunch of awkward + str(...) + mess every time we wanted to put a number into a sentence. Today we fix that with a tool called f-strings, and we learn how to do useful things with text — change its case, find pieces of it, count letters, even reverse it. By the end of class, you'll have built a "name analyzer" that takes a name and reports five different facts about it.

You'll need to remember from last time

• Three types — int, float, str.
• Type conversion — int(...), float(...), str(...).
• input(...) always returns a string.
• String concatenation — "Hello, " + name + "!" (the awkward way we did it last week).

Part A: f-strings (the good way)

Open Thonny and start a new file. Save it as strings.py.

Remember last week's age calculator? It looked like this:

print("In " + str(years) + " years, you'll be " + str(future_age) + ".")

Notice the + and str() everywhere. Annoying.

Here's the better way:

print(f"In {years} years, you'll be {future_age}.")

Same output. Way cleaner. That's an f-string.

What's an f-string

An f-string is a string with an f in front of the opening quote. Inside, you can put variables in curly braces and they get inserted automatically.

name = "Sam"
age = 12
print(f"My name is {name} and I'm {age} years old.")

Output: My name is Sam and I'm 12 years old.

The {name} and {age} get replaced with whatever's in those variables. No str() needed — Python figures out how to turn each variable into text for you.

You can also put whole expressions in the curly braces:

age = 12
print(f"Next year you'll be {age + 1}.")
print(f"In ten years you'll be {age + 10}.")

Output:

Next year you'll be 13.
In ten years you'll be 22.

The math runs first; the result goes into the string.

Try it

Build a file with your own f-string demos:

name = "Sam"
age = 12
favorite_color = "blue"

print(f"Hi, my name is {name}.")
print(f"I am {age} years old.")
print(f"My favorite color is {favorite_color}.")
print(f"In 7 years I'll be {age + 7}.")

Save. Run.

That's the entire f-string thing. Three rules:

1. Put f in front of the opening quote.
2. Put variables in {curly braces}.
3. Done.

"From now on, always use f-strings when building strings with variables in them. The old + str(...) + way still works, but f-strings are easier to read and easier to write."

Useful string methods

A method is a function that belongs to a value. You call it with a . after the value:

Try these:

name = "Sam"
print(name.upper())
print(name.lower())
print(name.replace("a", "X"))

Output:

SAM
sam
SXm

These methods don't change the variable — they return a new string. So name is still "Sam" after name.upper().

If you want to change name itself, you'd assign back to it:

name = name.upper()

.strip() — clean up input() (do this every time)

There's a quiet bug that gets people for years: input() and file reading often hand you strings with invisible whitespace on the ends. A trailing space. A leftover newline character. That whitespace makes string comparisons silently fail:

guess = input("Guess: ")
if guess == "yes":
    print("You got it!")

If the kid types yes and hits enter, this works fine — but if their input has a trailing space (easy to hit by accident), the comparison breaks. The string "yes " is not equal to "yes".

Fix: call .strip() on every input() you ever do.

guess = input("Guess: ").strip()

Now "yes ", "yes", and " yes " all become "yes". The comparison works.

From now on, every input() in the curriculum gets .strip() chained on it. It's one of those "always do this" habits — like wearing a seatbelt. Free protection.

.split() — break a string into a list of pieces

If a string has multiple words separated by spaces, .split(" ") breaks it into a list of those words. (Lists are coming in Session 8 — for now, just know it gives you back several pieces you can use.)

sentence = "the quick brown fox"
words = sentence.split(" ")
print(words)
# Output: ['the', 'quick', 'brown', 'fox']

You can split on any character, not just spaces. s.split(",") splits on commas. Useful when input comes in as a list of things the user typed: "red,blue,green".split(",") gives you each color separately.

We'll use .split() heavily once we hit lists. For now, just know it exists and what it does.

How long is a string?

len(s) tells you how many characters are in a string:

name = "Caleb"
print(len(name))   # 5

len is a function (not a method), so the syntax is len(name), not name.len().

Checkpoint: You've built a Python file that uses an f-string with at least two variables, and you've called .upper() (or .lower()) on a string and printed the result. This is the natural stop point if class is cut short.

Part B: Indexing, slicing, and a name analyzer

Strings are made of characters in order. Python lets you grab specific characters or pieces of a string by position.

Indexing

A string is like a row of boxes, numbered starting from 0:

"Caleb"
 C a l e b
 0 1 2 3 4

To get one character, use square brackets:

name = "Caleb"
print(name[0])    # C
print(name[1])    # a
print(name[4])    # b

You can also count from the end using negative numbers:

print(name[-1])   # b (last character)
print(name[-2])   # e (second-to-last)

Slicing

To get a piece of a string, use [start:end]. The slice includes start but stops before end:

name = "Caleb"
print(name[0:3])    # Cal (characters 0, 1, 2 — not 3)
print(name[1:4])    # ale (characters 1, 2, 3)
print(name[2:])     # leb (from 2 to the end)
print(name[:3])     # Cal (from the start to 3)

You can also slice with a step. The most useful step trick: reverse a string with [::-1]:

print(name[::-1])   # belaC

The double colon means "take every step character" — and -1 means "step backward." Don't memorize the syntax; just remember [::-1] reverses a string.

Build a name analyzer

Combine everything from Part A and Part B:

name = input("What's your name? ").strip()

print(f"Your name is {name}.")
print(f"It has {len(name)} characters.")
print(f"It starts with '{name[0]}' and ends with '{name[-1]}'.")
print(f"In all caps: {name.upper()}")
print(f"Reversed: {name[::-1]}")

Save. Run. Type your name.

(Notice .strip() on the input() — that's the new habit.)

The shell shows five facts about your name, all using f-strings.

That's the base goal for today.

Stretch — vowel counter

Count how many vowels are in the name. Use in to check if a character is in a string:

name = input("What's your name? ").lower()
vowel_count = 0

for letter in name:
    if letter in "aeiou":
        vowel_count = vowel_count + 1

print(f"{name} has {vowel_count} vowels.")

This combines: - .lower() to make the comparison case-insensitive - for letter in name: — a loop that goes through each letter of the string - if letter in "aeiou": — checks if the letter is one of the vowels - A counter variable that increases when we find a vowel - An f-string for the result

The for letter in name: syntax is new but easy: it's a for loop that visits each character of the string in order. We'll see this pattern a lot more once we get to lists.

Extension — palindrome checker

A palindrome is a word that reads the same forwards and backwards. "Mom" is a palindrome. "Racecar" is a palindrome. "Caleb" is not.

Build a palindrome checker:

word = input("Enter a word: ").lower()

if word == word[::-1]:
    print(f"'{word}' is a palindrome!")
else:
    print(f"'{word}' is not a palindrome.")

Try it with mom, racecar, taco, level, wasitacaroracatisaw.

The .lower() makes the comparison case-insensitive (so "Mom" and "mom" both work). The word[::-1] reverses the string. If the original equals the reverse, it's a palindrome.

Wrap-up

Before we leave, share with the room:

• What did you put into the name analyzer? Anything funny?
• For the kids who did the vowel counter — does your name have more vowels than you expected?
• For the kids who did the palindrome checker — what's the longest palindrome you found?

You learned today the most-used string operations in real Python: f-strings (for output), indexing (for getting one character), slicing (for getting pieces), and a few methods (for transforming).

F-strings will be in almost every program you write from now on. They're that common. The old + str(...) + mess is officially retired.

If you missed this session

Open Thonny and start a new file. Save as strings.py. Then:

1. Build an f-string demo: python name = "Sam" age = 12 print(f"My name is {name} and I'm {age} years old.") print(f"Next year I'll be {age + 1}.")

2. Try .upper(), .lower(), len() on a string. Print the results.

3. Try indexing: name[0], name[-1], name[1:3].

4. Build the name analyzer from Part B base goal.

About 30-40 minutes. If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• F-string formatting: f"{age:>5}" right-justifies in 5 spaces. f"{price:.2f}" shows 2 decimal places. There are many — try them and see.
• s.startswith("hello") and s.endswith("!") return True/False. Useful in conditionals.
• s.find("substring") returns the position where a substring first appears (or -1 if it's not in the string).
• Multi-line strings: """Hello\nWorld""" (triple quotes for strings that span lines).

What's next

Next week we deepen conditionals — combining multiple conditions with and, or, and not. Combined with f-strings, you'll be able to write programs that respond to multiple things at once and tell the user clearly what they decided.

Session 4: Conditionals — combining decisions

Phase 3 — Python basics · Session 4 of 16

What we're learning today

You already know if, elif, and else from Phase 2. Today we add three small but powerful words — and, or, and not — that let you combine multiple conditions into one decision. By the end of class, you'll have built a "rollercoaster eligibility checker" that asks the user several things and tells them if they can ride.

You'll need to remember from last time

• f-strings — f"Hello, {name}!".
• Comparison operators — >, <, ==, !=, >=, <=.
• if/elif/else from Phase 2 Session 6 — "if condition, do this; elif condition, do that; else, do the other."
• int(input(...)) for numeric input.

Part A: and, or, not

Open Thonny and start a new file. Save it as decisions.py.

In real life, decisions usually involve multiple things at once. "Can I ride the rollercoaster?" depends on age AND height. "Can I get my driver's license?" depends on age OR a special permit. "Should I take an umbrella?" depends on whether it's NOT sunny.

Python has three words for combining conditions:

and — both conditions

age = 15
height = 60

if age >= 13 and height >= 50:
    print("You can ride!")
else:
    print("Sorry, not yet.")

The if runs only if both parts are true. Age must be at least 13, and height must be at least 50. If either fails, the combined condition is false.

Try changing age = 12. The condition fails (because 12 isn't

= 13). Try changing height = 40. Same — fails because height isn't >= 50.

or — at least one

name = input("What's your name? ")

if name == "Sam" or name == "Alex" or name == "Jordan":
    print("Welcome, friend!")
else:
    print(f"Hi, {name}.")

The if runs if the name matches any of the three. The or operator means "at least one of these has to be true."

not — the opposite

is_raining = True

if not is_raining:
    print("Leave the umbrella at home.")
else:
    print("Bring your umbrella!")

not flips a true to false (or vice versa). not True is False. not False is True.

not is most useful when the variable already has a yes/no meaning. not is_raining reads naturally: "if it's not raining."

Combining all three

You can mix them. Here's a full example:

age = 14
has_permission = True

if (age >= 13 or has_permission) and not age < 8:
    print("You can play this game.")
else:
    print("Not allowed.")

This checks: "if (you're 13 or older OR you have permission), AND (you're NOT under 8), then you can play."

The parentheses group the conditions like math. and is checked after or by default — using parentheses makes the order explicit and makes the code easier to read.

Tip: when conditions get complicated, put each part on its own line. Python lets you split a long condition with backslashes or by surrounding it with parentheses. Most programmers use parentheses. We'll see that in the rollercoaster project.

Checkpoint: You've used and, or, and not in at least one program, and you've seen how Python evaluates a combined condition. This is the natural stop point if class is cut short.

Part B: The rollercoaster eligibility checker

Time to build something that uses all this.

What you're building

A program that asks the user their age and height, then tells them whether they can ride the rollercoaster. The rules:

• You must be at least 13 years old.
• You must be at least 48 inches tall.

Both conditions must be true to ride.

Base goal

print("Welcome to the Rollercoaster Eligibility Checker!")

age = int(input("How old are you? "))
height = int(input("How tall are you, in inches? "))

if age >= 13 and height >= 48:
    print("You can ride! Have fun!")
else:
    print("Sorry, you can't ride this one.")

Save. Run. Try a few combinations: - age = 15, height = 60 — should pass. - age = 10, height = 70 — should fail (too young). - age = 14, height = 40 — should fail (too short).

That's the base goal. Working program, simple combined condition.

Stretch — tell them WHY

A vague "sorry, you can't ride" isn't very helpful. Use multiple branches to tell the user exactly what's wrong:

if age >= 13 and height >= 48:
    print("You can ride! Have fun!")
elif age >= 13 and height < 48:
    print("You're old enough, but you're a little too short.")
elif age < 13 and height >= 48:
    print("You're tall enough, but you're a little too young.")
else:
    print("You're both too young and too short. Come back in a few years!")

Now the program gives specific feedback for each failure case. Four possible outcomes; one branch per outcome.

Extension — refactor with intermediate variables

The repeated age >= 13 and height >= 48 checks are awkward. Save the results in named variables for cleaner code:

print("Welcome to the Rollercoaster Eligibility Checker!")

age = int(input("How old are you? "))
height = int(input("How tall are you, in inches? "))

old_enough = age >= 13
tall_enough = height >= 48

if old_enough and tall_enough:
    print("You can ride! Have fun!")
elif old_enough:
    print("You're old enough, but you're a little too short.")
elif tall_enough:
    print("You're tall enough, but you're a little too young.")
else:
    print("You're both too young and too short. Come back in a few years!")

Notice what's different:

• old_enough = age >= 13 saves the result of the comparison (a True or False value) in a variable. This is called a boolean — a value that's either True or False.
• The if statements now read more like English.
• The repetition is gone.

This is a common trick in real code: when conditions are repeated or complex, give them names.

You could push this even further:

if old_enough and tall_enough:
    print("You can ride! Have fun!")
else:
    if not old_enough:
        print("- You're too young.")
    if not tall_enough:
        print("- You're too short.")
    print("Try again later!")

Now you list all the failures, not just the first one. That uses not to invert each check.

Wrap-up

Before we leave, share with the room:

• For the kids who built the base — did your eligibility check work for the test cases?
• For the stretch — was anyone surprised by the "old enough but too short" message?
• For the extension — did the named variables version feel cleaner?

You learned today the three small words that make Python's conditionals genuinely powerful. and, or, not turn simple yes/no checks into real decisions about complicated situations. Every program that handles "what should we do here?" ends up using these.

You also met booleans — values that are True or False. Booleans are the third major type after numbers and strings, and you'll see them constantly from here on.

If you missed this session

Open Thonny and start a new file. Save as decisions.py. Then:

1. Try basic and, or, not examples: python age = 15 if age >= 13 and age < 20: print("Teenager.")

2. Build the rollercoaster eligibility checker (Part B base): - Ask for age and height - Check age >= 13 and height >= 48 - Print "you can ride" or "sorry"

3. Try the stretch — separate branches for each failure case.

About 30 minutes. If you get stuck, ask your buddy at the start of next class.

Stretch and extension ideas

• The order of or and and matters when they're mixed. True or True and False is True because and is evaluated first. Use parentheses when in doubt: (True or True) and False is False.
• True and False (with capital T and F) are Python's built-in booleans. You can assign them directly: is_raining = True.
• The bool() function converts other values to True/False. bool(1) is True; bool(0) is False; bool("") is False; bool("hello") is True. Try them.
• Compound conditions with three or more parts: if x > 0 and y > 0 and z > 0: — works for any number of parts.

What's next

Next week we deepen loops and meet the Thonny debugger — a tool that lets you watch your program run line by line. The debugger is the single most useful thing for figuring out why your program isn't doing what you thought it would. By the end of next week, you'll have a new debugging superpower.

Session 5: Loops (deeper) and the Thonny debugger

Phase 3 — Python basics · Session 5 of 16

What we're learning today

Two new things today, both useful: the while loop (a different kind of loop from the for loop you already know), and the Thonny debugger — a tool that lets you watch your program run line by line and see exactly what's happening inside. The debugger is the single most useful tool for figuring out why your code isn't doing what you thought it would. By the end of class, you'll have a new debugging superpower.

You'll need to remember from last time

• for loops — for i in range(N): runs N times.
• Combined conditionals — and, or, not.
• Booleans — True and False.
• Indentation — code inside a loop or if is indented.

Part A: The while loop

Open Thonny and start a new file. Save it as while_loop.py.

What while does

A for loop runs a known number of times — for i in range(10): runs ten times. Period.

A while loop runs as long as a condition is true. The program checks the condition before each iteration; if it's true, run the body and check again; if it's false, stop.

count = 1
while count <= 5:
    print(f"Count is {count}")
    count = count + 1

print("Done!")

Save. Run.

Count is 1
Count is 2
Count is 3
Count is 4
Count is 5
Done!

Walk through what happened:

• count = 1 — start the variable at 1.
• while count <= 5: — check: is 1 <= 5? Yes. Run the body.
• Inside: print, then count = count + 1 (now count is 2).
• Back to the while check: is 2 <= 5? Yes. Run again.
• ...continue until count is 6. Now 6 <= 5 is False. Stop.
• After the loop, "Done!" prints.

The structure: while CONDITION: then indented body. Same indentation rule as if and for.

Why while instead of for?

for loops are great when you know how many times to repeat — "draw 10 squares" or "for each letter in this word."

while loops are great when you don't know how many times — "keep asking the user until they give a valid answer" or "keep playing until the player wins."

Try this — a guess-the-number style program:

secret = 7
guess = 0   # start with anything that's not the secret

while guess != secret:
    guess = int(input("Guess a number: "))
    if guess != secret:
        print("Nope, try again.")

print(f"You got it! The number was {secret}.")

Save. Run. Try to guess 7. The loop runs until you guess right.

This wouldn't be easy with a for loop — you don't know how many guesses it'll take.

Watch out for infinite loops

The dangerous thing about while loops: if the condition never becomes false, the loop runs forever. This is called an infinite loop.

count = 1
while count <= 5:
    print(count)
    # OOPS: forgot to update count!

Run this. The shell prints 1 over and over forever. Press the red Stop button in Thonny (or Ctrl-C in the shell) to kill it.

Every while loop must do something inside that eventually makes the condition false. Most often that's updating a variable (like count = count + 1 in the example).

break

Sometimes you want to exit a loop early. The break statement does that:

while True:
    answer = input("Type 'quit' to stop: ")
    if answer == "quit":
        break
    print(f"You said: {answer}")

print("Goodbye!")

while True: is a deliberate "infinite" loop — but break exits it when the user types "quit." Common pattern.

Checkpoint: You've written a while loop that runs at least three times before stopping (either by a count variable or by user input). This is the natural stop point if class is cut short.

Part B: The Thonny debugger

Now for the debugging superpower.

What the debugger is

Most of the time when your code is wrong, you read the code, spot the bug, fix it. But sometimes — especially with loops and multi-step programs — you can't tell what's wrong by reading. Variables change in ways you didn't expect. The control flow goes somewhere you didn't intend.

The debugger lets you watch your program run line by line and see the value of every variable at every step. It's like having superpowered slow-motion vision.

A buggy program

Type this exactly. There's a deliberate bug:

word = "hello"
vowel_count = 0

for letter in word:
    if letter in "aeiou":
        vowel_count = 1

print(f"Vowels in '{word}': {vowel_count}")

Save as vowel_bug.py. Run.

Vowels in 'hello': 1

But "hello" has two vowels (e, o). Why does the program say 1? Reading the code carefully, you might spot it. But let's use the debugger to see the bug happen.

Running with the debugger

In Thonny, look at the toolbar. Next to the green Run button, there are some other buttons. The one that looks like a bug icon is "Debug current script."

Click the bug icon (or press Ctrl-F5).

Two things change:

• The program pauses at the first line, with that line highlighted.
• A panel appears (often on the right) showing variables and their values. Right now, no variables exist yet.

Stepping through

Find the "Step over" button (looks like an arrow stepping over a line — usually called Step Over, F6 on most systems). Click it once.

The first line ran. Look at the variables panel — word is now "hello". You can see the variable that just got created.

Click "Step Over" again. Now vowel_count is 0.

Click again. The for loop starts. Watch what letter is — it's "h". The loop is on its first iteration, looking at the first character of "hello".

Click again. The if checks: is "h" in "aeiou"? No. Skip the body.

Click again. Loop continues. Now letter is "e".

Click again. if checks: is "e" in "aeiou"? Yes! Run the body.

Click again. vowel_count = 1. The variables panel updates — vowel_count is now 1.

Click again. Loop continues. Now letter is "l". if is False, skip.

Click. letter is "l" again. Skip.

Click. letter is "o". if is True! Run the body.

Click. vowel_count = 1. Wait — it's still 1, not 2.

That's the bug. Every time the program finds a vowel, it sets vowel_count to 1 (overwriting the previous value), instead of adding 1 to the existing count.

Fix the bug

Change vowel_count = 1 to vowel_count = vowel_count + 1.

Save. Run normally (green button). Output:

Vowels in 'hello': 2

You found and fixed a bug by watching the program run. That's the debugger.

Why this matters

You'll often be in this situation: your program runs but does the wrong thing, and you don't know why. Reading the code more carefully helps sometimes. The debugger helps every time — it shows you exactly what's happening.

The same workflow works for any Python program:

1. Click the bug icon to start debugging.
2. Watch the variables panel.
3. Click "Step Over" to advance one line at a time.
4. Notice when a variable becomes wrong. That's where the bug is.

You can also click "Resume" (or F8) to run normally until the next error or until the program ends.

Try it

Open one of your earlier programs (the rollercoaster checker, the name analyzer, or the age calculator). Run it with the debugger. Step through. Watch the variables change.

You don't need to find a bug — just practice using the debugger. The fluency you build by using it on working code makes it much easier to use when you actually need it.

Wrap-up

Before we leave, share with the room:

• What's a situation where a while loop made more sense than a for loop?
• For the debugger demo — was it surprising to see the vowel_count being set to 1 every time?
• For the kids who debugged an earlier program — did anything surprise you about how it ran?

You learned today the most important debugging skill in any programming language: watching your program execute, step by step. The Thonny debugger is small and friendly; debuggers in bigger languages (like JavaScript or Java) work the same way but with more features. The mental model carries over.

You also learned while — the loop for "until something is true." Combined with for (for known counts), these are the two loop tools you'll use for the rest of your programming life.

If you missed this session

Open Thonny and start a new file. Save as while_loop.py. Then: