Week 2: Statements, Input/Output, and Errors

🎯 Objectives

This is the first week of graded content. By the end of the week you should be able to:

• Read input with input() and convert it to the type you actually need.
• Print output with print() that matches a required format exactly.
• Import and use functions from a standard-library module such as math.
• Tell apart the kinds of errors you will meet: those caught before your code runs (for example, SyntaxError), those that happen while it runs (for example, ArithmeticError), and style violations reported by ruff.

📚 Study menu

This week moves through three things in class: variables with input and output, then type conversion with the math module and the errors Python reports, and finally checking your code for style with ruff. The menu below is for consolidating that work on your own and getting ready for Quiz 1.

Read about it

Use whichever book you settled on last week, or switch if the first one didn't suit you. Both cover the same ground; the sections listed here are the ones that match this week.

Python for Everybody

• 2. Variables, Expressions, and Statements: sections 2.1 through 2.6, plus 2.10 on asking the user for input.
• 5. Functions: sections 5.1 through 5.4, especially type conversion and math functions.
• 1. Why Program?: sections 1.11 and 1.12, on what can go wrong and on debugging.
• 3. Debugging Interlude 1: section 3.4, "Know Your Error Messages."

How to Think Like a Computer Scientist

• 2. Simple Python Data: sections 2.1 through 2.8, covering values and data types, type conversion, variables, statements, operators, and input.
• 5. Python Modules: sections 5.1 through 5.3. This is the clearest treatment of importing and of the math module in either book.
• 1. General Introduction: sections 1.6 through 1.10, on debugging and on the kinds of errors.
• 3. Debugging Interlude 1: section 3.4, "Know Your Error Messages."

Finish your setup

The style lab sets up things that live on one machine only: the color setting, the virtual environment, and the installed ruff tool. If you do that work in the computer lab, you still need to do it on your laptop, or the other way around. That lab falls at the end of the week, so finishing the second machine will probably spill into the weekend. Get it done before the next week starts rather than discovering the gap when something is due. You will know it worked when !ruff check runs in Thonny's Shell on both machines.

Predict before you run

This is the single most valuable habit you can build this week, and it costs almost no extra time.

You already did it once in the team activity, when you worked out the value of hot before testing it. Make that the default rather than the exception. Before you run any program, write down what you think it will print, on paper or in a comment rather than just in your head. Then run it and compare. A wrong guess has found you a real gap in your understanding, which is worth more than a program that happens to work.

Do this for the type as well as the value. The team activity showed you what happens when you take a value straight from input() and try to do arithmetic with it. input() always hands back a string, even when the user types a number, and a great deal of Week 2 confusion traces back to forgetting that.

Practice telling errors apart

Quiz 1 will ask you to sort errors into kinds, so practice the sorting rather than just fixing whatever breaks. There are three kinds this week:

• Caught before your code runs. Python never starts executing. A missing colon or an unmatched parenthesis produces a SyntaxError.
• Happens while it runs. The program starts, produces some output, and then stops. Dividing by zero is the classic case; it produces a ZeroDivisionError, which is one kind of ArithmeticError.
• A style violation. The program runs correctly and produces the right answer, and ruff still has something to say about it. payroll.py, from the style lab, is exactly this: it works fine, and every problem in it is a matter of style.

The team activity had you record the type of each error you hit, and that technique is worth keeping: the type is the first word of the last line of the error message.

A good exercise is to take a program that already works and break it on purpose, three different ways, one for each kind. Sort each break into its kind before you run it, then check. Deliberately breaking working code teaches you more about error messages than accidentally breaking it does, because you already know what the answer should have been.

• Python's official tutorial, "Errors and Exceptions". Read sections 8.1 and 8.2 only.
• PEP 8, the Python style guide. This is the document behind the rules ruff checks. Skim it to see where the conventions come from; nobody reads it end to end.
• Ruff documentation, the Rules page, for looking up what a particular violation code means.

Write your own programs

In class you will write programs that read two or more inputs, convert them, calculate something, and print a result in a required format. That shape, read and convert and calculate and print, is the core pattern of Week 2, and it is the most likely thing a quiz will ask you to produce.

The Week 2 practice problems include many examples of this pattern. Write at least three of these programs, and submit them to Gradescope to check your work.

Then practice this pattern on a subject of your own choosing rather than repeating the one from class. Split a restaurant bill, convert units, average a set of scores, work out how many full boxes something packs into. Run each program several times with different inputs, including inputs you expect to cause trouble, and check that the printed sentence still reads correctly every time.

Save your work in your Week02 folder, then commit and push it. Once you have ruff installed, run !ruff check on each program before you call it finished. Fix what ruff reports by hand instead of running ruff format. The style lab has you correct payroll.py by hand for a reason: applying a convention yourself is what makes you remember it.

Learn to look things up

You are not expected to memorize what is in the math module. You are expected to be able to find out. Reading official documentation is an ordinary programming skill, and this is a good week to start, because math is small enough to explore comfortably.

• Python documentation, the math module. Import it, then try three or four of its functions in Thonny's Shell to see what they return.
• Python documentation, the print() function. Look up what sep and end do, and try changing them. They matter when your output has to match a required format exactly.

Try an AI tutor

AI can write every program in this week's practice set in about two seconds. That is exactly the problem. Quiz 1 asks you to reason about code by hand, so this week the useful move is to make AI test you rather than answer for you.

Three prompts worth trying:

"Write five very short Python programs. Some should have an error that Python catches before running, some should have an error that happens while running, and some should run correctly but have a style problem that a linter would flag. Don't tell me which is which. Let me classify each one first, then tell me whether I was right."

"Give me a short Python program that reads two numbers with input(), converts them, and prints a sentence containing the result. Show me the program and tell me what the user types, but do not tell me the output. Ask me what it prints."

"Here is an error message I got: [paste it]. Explain in plain language what Python is telling me and what usually causes this, but do not fix my code. I want to find it myself."

Notice what those three prompts have in common: in each one, you are still the person doing the thinking. If you finish a study session and AI produced the answers while you read along, you have not practiced anything the quiz will ask for.

✍️ Reflection

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

• Read one or more textbook chapters
• Finished the virtual environment and ruff setup on my other machine
• Wrote one or more programs of my own
• Predicted output before running a program
• Ran !ruff check on my own code
• Looked something up in the official Python documentation
• Watched a video or read another resource
• Asked an AI tutor to test my knowledge
• 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. Did you write down what a program would print before running it? How did it go? Were your guesses usually right, sometimes right, or mostly wrong? Give one example you got wrong and what you learned from it. If you were often wrong, say so plainly; that is the most useful thing you could report, and it tells your instructor exactly what to work on with you.

4. Describe one error you actually hit this week. What was the error, and which of the three kinds was it: caught before your code ran, happened while it was running, or a style violation reported by ruff? How did you figure out what was wrong?

5. Of this week's four objectives, which feels solid and which feels shaky? The four are reading input and converting types, printing in an exact format, importing and using a module such as math, and telling the kinds of errors apart. Name your shakiest one specifically, and say what you plan to do about it before Quiz 1.

6. Did you use an AI tool this week, and did it build your understanding or replace it? After this week's studying, how confident are you that you could read a short program on paper and say what it prints? If you found a video, article, or tutorial that helped something click, drop the link and one line on why it helped; we collect these to improve the study menu for future students.

7. Paste one or two programs you wrote outside of class this week. Pick the ones you are proudest of, or the ones you learned the most from writing.