Week 3: Expressions, Types, and Indexing

🎯 Objectives

Last week was about getting a program to run. This week is about being able to say what a piece of code is, its type and its value, before Python tells you. That sounds like a smaller skill than writing a program that works, and it is actually the harder one, because Python is no longer there to check your answer.

By the end of the week you should be able to:

• Predict, on paper, the type and the value of an arithmetic or string expression built from +, -, *, /, //, %, **, string concatenation and repetition, and indexing a single character.
• Write expressions and f-strings that turn given inputs into a required numeric or formatted result.
• Explain why an expression fails, and name the type of error it raises.

📚 Study menu

Class moves through three things this week: objects and types and the precedence of arithmetic operators, then Python's three division operators and the errors that bad expressions raise, and finally string concatenation, repetition, indexing, and f-strings. The menu below is for consolidating that work and for arriving at Quiz 1 able to do it with a pencil.

This is a menu, not an assignment. Nobody does all of it, and you are not behind if you pick two items and do them properly. If you are not sure where to start, work the Week 3 questions on the Unit 1 review page first. Whatever you get wrong there tells you which items below deserve your time.

If you only have an hour

Some weeks that is all there is, so here is the order to spend it in.

1. Ten minutes. The Week 3 questions on the review page, on paper, to find out where you stand.
2. Twenty minutes. A dozen expressions of your own, type and value, written in pen and then checked one at a time in Thonny's Shell.
3. Fifteen minutes. The specifier table in the f-string lab, with the Output column covered.
4. Fifteen minutes. One practice program whose output has to match exactly.

Everything else on this menu is worth doing. That is the order to do it in when the week gets away from you.

Read about it

Use whichever book you have settled into. The sections listed here are the ones that match this week, and both books put this material in two different places: the rest of the arithmetic chapter you started last week, and the beginning of the strings chapter much later in the book.

Python for Everybody

• 2. Variables, Expressions, and Statements: sections 2.7 through 2.9, on order of operations, the modulus operator, and string operations.
• 7. Strings: sections 7.1 and 7.2, on a string as a sequence and on len().
• If integers versus floats still feel blurry, go back to section 2.1, on values and types.

How to Think Like a Computer Scientist

• 2. Simple Python Data: section 2.9 on order of operations, and a second pass over 2.7 on operators and operands, this time paying attention to // and % rather than to + and *.
• 9. Strings: sections 9.1 through 9.4, then 9.6. Section 9.4, on the index operator, is the one to read twice.

Drill type and value on paper

Last week asked you to predict a program's output before running it. This week gives that habit a specific shape, and it happens to be the exact shape of a quiz question: an expression, its type, and its value.

The Unit 1 review page has three of these tables under "predicting expression type and value." Fill one in on paper, in pen, with no computer open, and save the other two for a timed run later in the week. Write int, float, or str in the type column, and if a row raises an error, write the name of the error instead of a value. Only then open Thonny's Shell and check each row: type the expression, press Enter, and the Shell prints the value. Wrap it in type(), as in type(8 / 4), and it prints the type. The Shell is the fastest checking tool you have, and one row at a time is exactly how it wants to be used.

What you are looking for is rules, not answers. A dozen rows in, you should be able to state these without hesitating:

• / always produces a float, even when the answer comes out whole.
• // and % produce an int only when both operands are integers. One float anywhere in the expression makes the result a float.
• Mixing an int and a float in any arithmetic gives you a float, and that is true of ** as well, including when the exponent is the fractional one.
• + wants two numbers or two strings. * will also take a string and an integer, which repeats the string. Every other combination across those two types is a TypeError.
• Indexing a string always hands back a str one character long, never a number, even when the character you pulled out is a digit. This is why "cs149"[3] + 1 fails and int("cs149"[3]) + 1 does not.
• An index past the end of the string is an IndexError, and an index that is not a whole number is a TypeError.

One five-minute detour worth taking. In the Shell, try 0.1 + 0.2, then round(2.675, 2). Neither result is a bug, in Python or in your machine, and knowing why keeps you from chasing one later.

• Python documentation, Floating-Point Arithmetic: Issues and Limitations.
• 0.30000000000000004.com, which is the same problem in every programming language, because it was never a Python problem.

Build the reference card you cannot bring

Quiz 1 is closed book, so this is a strange suggestion until you see the point: spend twenty minutes making the one-page reference sheet you will not be allowed to use. Making it is the studying. Carrying it would have been the shortcut.

On one side of one sheet of paper, from memory and with the books closed, write down the seven arithmetic operators with a small example and the type each example produces, the precedence order from highest to lowest, the two things + and * do with strings and what each one refuses to do, what indexing looks like for the first character and the last character and one past the end, and four format specifiers you would actually use.

Now check it against the books and fix your mistakes in a different color, so you can see at a glance what you did not know. The colored parts are your study list. Then put the card away and rewrite it from scratch two days later. The second attempt is where the learning happens.

Write programs whose output has to look right

The shape from last week does not change: read some input, convert it, calculate, print. What changes is that the printing gets fussy, and f-strings are the tool for being fussy on purpose.

Start with the specifier table in the f-string lab, with the Output column covered, predicting each row before you look. Sixteen rows there cover nearly everything you will need this semester, and predicting them now is quicker than looking each one up while you are mid-program.

Then write some programs. The Week 3 practice problems are the place to start, and each one has a Gradescope assignment so you can check your own work. Two extra challenges at the bottom of that page each need a specifier the six exercises never ask for, if you want to push further.

Save your work in a Week03 folder inside ~/CS149, then commit and push it. Run !ruff check on each program before you call it finished, and fix what it reports by hand.

Study with somebody

This is the first week where the material is genuinely better practiced with another person, because the quiz asks you to explain and justify, and explaining out loud is the only way to find out whether you can.

Find one classmate, sit down with paper and no computer, and spend fifteen minutes. You each write five expressions using this week's operators, at least one of which raises an error, then trade papers and fill in type and value. When you disagree about a row, argue it out before you check with Python. The argument is the studying; the check is just the scoreboard.

Then take turns answering out loud, in two sentences and without notes. Why does 7 / 2 give 3.5 but 7 // 2 give 3? Why does "7" + 2 fail when 7 + 2 and "7" + "2" both work? A question you cannot answer out loud is one you do not have yet, however familiar it looked on the page.

No one to work with? Explain it to a voice memo on your phone, or to a roommate who has never programmed. Studying together like this is encouraged all semester, but the quiz itself is yours alone, and so is anything you submit for a grade.

Sit a timed dry run

A rehearsal under quiz conditions is a different exercise from working through problems at your own pace, and a much better predictor of how next week will go.

Print the Unit 1 review questions, set a timer for 30 minutes, and put away your notes, your laptop, and your phone. The page has questions for all six objectives from Weeks 2 and 3, and the quiz covers both weeks, so do not skip the Week 2 half. If you already worked some of the tables earlier in the week, write fresh expressions of your own for those.

When the timer goes off, stop, and only then start checking, in the Shell rather than by asking anything to tell you the answers. Then do the part that actually matters: for every question you got wrong, write one line saying why you got it wrong. "I forgot / always makes a float" and "I mixed up // and %" and "I ran out of time" are three completely different problems with three completely different fixes, and the only way to tell which one you have is to look at your own wrong answers.

Try an AI tutor

Something changes about AI this week. Every question on Quiz 1 is one an AI answers instantly and perfectly, which makes asking it for answers feel productive while teaching you nothing at all. So make it run the drills and keep the pencil yourself.

Three prompts worth trying:

"Generate a table of twelve Python expressions using only +, -, *, /, //, %, **, string concatenation, string repetition, and single-character indexing. Some of them should raise an error. Give me the table with the Type and Value columns blank and do not fill them in. After I answer, grade me one row at a time and explain only the rows I got wrong."

"I am going to explain Python's rules for what type an arithmetic expression produces. Tell me what is missing or wrong in my explanation, but do not give me the correct rules. Instead, ask me a question that would make me notice the gap myself."

"Here is an f-string I wrote: [paste it]. I want the output to look exactly like this: [paste it]. Do not rewrite my code. Tell me which part of my format specifier is doing the wrong thing and let me fix it."

There is also a specific reason to be skeptical this week. On operator precedence, on which types // returns, and on floating-point rounding, AI tools are sometimes confidently and specifically wrong. Python is the authority on what Python does, so when the two disagree, the Shell wins. Checking AI's arithmetic in the Shell is a genuinely useful exercise, and it is the reverse of the usual direction.

✍️ Reflection

1. What did you do this week? (Check all that apply.)

• Read the sections listed for one or more of the textbooks
• Filled in a type and value table on paper and checked it in the Shell
• Worked through the f-string specifier table in the lab
• Built a one-page reference card from memory
• Wrote one or more programs of my own
• Studied with a classmate, or explained something out loud
• Sat a timed dry run with the review questions
• Asked an AI tutor to drill or test me
• Something else (tell us in the short answers)

2. Roughly how much time did you spend on CS 149 outside of class this week?

• Under 1 hour
• 1–2 hours
• 3–4 hours
• 5–6 hours
• 7+ hours

3. How ready do you feel for Quiz 1 right now?

• Ready: I could take it today
• Mostly ready: one or two topics left to shore up
• Shaky: I can write programs that work, but reading code on paper is hard
• Not ready: I need help before the quiz

4. Give one expression you predicted wrong this week. Write the expression, what you thought its type and value were, and what they actually turned out to be. Then name the rule you were using that turned out to be wrong. The wrong rule is the useful part, because it is what will catch you again next week if nobody fixes it.

5. Of this week's three objectives, which one feels solid and which one feels shakiest? The three are predicting the type and value of an expression on paper, writing expressions and f-strings that produce a required format, and explaining why an expression fails and naming the error. Name your shakiest one specifically, and say what you are going to do about it before the quiz.

6. What is one thing you want gone over in class before Quiz 1? Be as specific as you can: "the difference between // and %" is useful, and "everything" is not. Answer this even if you feel confident, by naming the topic you would least like to see on the quiz. Class time before a quiz gets spent on whatever shows up most often in these answers, so this question is the one that actually changes what happens next week.

7. Did you use an AI tool this week, and did it build your understanding or replace it? This week the honest test is concrete: could you fill in a twelve-row table of expressions with a pencil, alone, in ten minutes? If you found a video, article, or tutorial that made something click, drop the link and one line on why it helped; we collect these to improve the study menu for future students.

8. Paste one or two programs you wrote outside of class this week. Pick the ones where getting the output to look exactly right took you the longest.