Decisions with if, elif, and match
Express mutually exclusive decisions with readable conditions, truth values, membership tests, and structural pattern matching where it genuinely helps.
Before this lesson
Design complete branch sets
Use truthiness without hiding intent
Recognize appropriate match cases
The short answer
Use if for the first condition, elif for alternative branches, and else for the remaining case. Order branches from specific to general, keep predicates readable, and use match when matching structured shapes or a closed set of clear cases.
Build the mental model
A condition is evaluated as true or false. Empty collections, empty strings, numeric zero, and None are falsey, but explicit comparisons can communicate a domain rule more clearly. Short-circuit and/or stop as soon as the result is known.
The central idea in this lesson is branch design. Read the rule, predict a concrete outcome, and then run the smallest example that can confirm or reject the prediction. This separates knowledge from familiarity with syntax.
Make the design choice explicit
Use guard clauses to reject invalid states early, then keep the successful path less indented. Choose match for command tokens or structured data when it is clearer than repeated equality checks—not merely because the syntax is available.
score = 84
if not 0 <= score <= 100:
result = "invalid"
elif score >= 90:
result = "A"
elif score >= 80:
result = "B"
elif score >= 70:
result = "C"
else:
result = "needs review"
print(result)Expected output
B
Trace the example before running it. Identify each input, transformation, returned value, and side effect. Then change one boundary value and explain why the new behavior follows from the rule rather than memorizing the output.
Recognize failure modes
Overlapping ranges make branch order important. Test exact boundaries and the else path. Avoid comparing booleans with == True; use the boolean expression itself unless distinguishing True from other truthy objects is required.
Use a professional practice loop
Turn the concept into a repeatable workflow: write down the expected behavior, implement one coherent change, run a representative example, and retain a regression check. If the result surprises you, capture the exact input and error before changing anything.
Review the program for names, boundaries, and hidden side effects. A solution is complete when another developer can understand its contract, reproduce its setup, and verify both the successful path and one meaningful failure path.
Quick knowledge check
Answer before you reveal.
01Why place invalid-range checks first?
A guard clause prevents later business rules from operating on values outside their valid domain.
02What four steps make the practice loop reliable?
Predict the behavior, make one coherent change, run it, and retain a check that detects regression.
Exercise
Practice challenge
Classify a temperature into invalid, freezing, cool, warm, or hot with documented inclusive boundaries.
Requirements
- The successful path produces the documented result
- At least one boundary or invalid case is handled deliberately
- Calculation or domain logic is separated from console interaction
Optional extension: Add one automated regression check for the most important rule.
Open in Python compilerLesson checkpoint
One small step locks it in
Mark this lesson complete, then keep the momentum going.
Clear up the details
Frequently asked questions
Is branch design only important in large programs?
No. Small programs reveal the same rules with less noise, and learning the rule early prevents fragile habits from becoming architecture.
Should I memorize every API used here?
No. Memorize the mental model and how to verify behavior. Use documentation for exact names and parameters when needed.
How do I know the exercise is finished?
Meet every success criterion, test at least one boundary or failure case, and explain why the output follows from the code.