Control Flow: Intermediate

Most functions that handle real data spend their first lines deciding whether the input deserves any work. A payment amount can be missing or negative. It can also arrive in a currency the warehouse never converts. How those checks are arranged decides whether the function reads top to bottom or makes you track which if you are standing in.

A guard clause lives inside a function, so here is the slice of function syntax it relies on. The line def to_dollars(amount_cents, currency): names a block of code and the 2 values it receives, and the indented lines under it form its body. Writing to_dollars(1999, "USD") runs that body with amount_cents set to 1999 and currency set to "USD". The keyword return hands a value back to the caller and ends the call on the spot: no line below it runs for that call. A function that reaches the end of its body without a return gives back None.

Read it the way the next engineer will. To find out what happens when amount_cents is None, you start at the if on line 2 and scan down to the else on line 10. The rule and its outcome sit 9 lines apart, and the only line doing real work, the division, is buried under 3 if statements. A fourth rule adds another step and re-indents everything inside it.

Each guard may rely on the ones above it. The test amount_cents < 0 needs a value that can be ordered against 0, and None can't be, so the None check sits above it. The rule: every guard comes before any comparison that would fail on a value no earlier guard has ruled out. The None guard rules out exactly 1 value. It doesn't make amount_cents a number: a string such as "50" passes it and fails at < 0 the same way. Confirming that a value is a number takes a type check, which the last section of this lesson covers. In the animation, the call with None and "EUR" returned at the first guard, so the currency test never ran. Swap the first 2 guards and that protection is gone.

Guards fit cases that stop the work: missing, malformed, out of range. When both outcomes are ordinary results, such as a domestic fee and an international fee, a plain if/else states the choice as it is, and turning one side into a fake guard hides that both sides are equal partners. A well-shaped function usually opens with a few guards and ends with a single short decision.

Converting a staircase into guards means writing the opposite of each condition the staircase kept going on. Every comparison operator has an exact opposite, and the table below pairs them. The boundary value is where a wrong inversion hides: the staircase accepted amount_cents >= 0, so the guard must leave on amount_cents < 0. Writing <= 0 instead rejects a 0-cent amount, such as a fully discounted order, and nothing else, so every test that uses ordinary amounts still passes.

Range checks are everywhere in a pipeline: a latency between 0 and 500 ms, an hour between 0 and 23, a timestamp inside a partition's window. Python lets you write 0 <= hour <= 23 the way a math textbook would, and it means what the textbook means.

Python reads a < b < c as a < b and b < c, with one difference: the middle operand is evaluated once. A chain can be as long as you like, and it is True only when every adjacent pair is True. Any comparison operator you know can join a chain, == and != included, and is too.

hour <= 23 and hour < 24 give the same answer for every whole hour, which is why 24 failed both. They stop agreeing on values with fractions. The form low <= x < high, called half-open, includes its lower bound and excludes its upper one, so adjacent bands written this way share a boundary without overlapping: every value lands in exactly 1 band. Daily partitions follow the same rule, so an event stamped exactly at midnight belongs to the new day and never to both.

With the closed bands on the left, a latency of 99.5 is too big for fast and too small for normal, so it matches no band at all. Closed bands that share a number fail the other way. With ms <= 100 and 100 <= ms, 100 qualifies for both, and only the order of the branches decides the label.

Parentheses end a chain: (5 > 3) > 1 computes True first and then compares it with 1, and True behaves as 1 in arithmetic and comparisons, so 1 > 1 is False. 3 > 2 == True chains into 2 == True, which is False. 1 != 2 != 1 comes out True even though its first and last values are equal, because a chain only compares neighbours and says nothing about its ends.

Every link in a chain is a real comparison, so each pair must support ordering. A value read from a CSV or a web form arrives as a string, and a chain that puts it next to a number stops at the first link. If you convert the value with int("85") where it enters, the chain works on numbers from then on.

Every test looks at the same subject, status, so a reader knows the whole ladder is one decision. Each test is also a complete case: an equality, alternatives joined by or, or a chained range. The last return is a deliberate catch-all, so a 301 nobody planned for produces a visible alert instead of reaching the end of the function and returning None.

Alternatives in a single branch are joined with or: status == 200 or status == 204 is True when either equality holds. Joining them with and instead produces a branch that can never run, because 1 status can't equal 200 and 204 at the same time. Python raises no error for it. Every 204 falls through to the next test, and in this ladder that means the catch-all, so a successful response gets reported as unexpected.

A match statement evaluates its subject once, then tries each case from top to bottom. The first case that fits runs its block and the statement ends, with no fall-through into the next case. When nothing fits and there's no case _:, the statement does nothing and raises no error. An if/elif ladder without a catch-all fails just as silently.

Many branches exist only to give a single variable one of 2 values. Written as a 4-line if/else, the reader has to confirm that both arms assign the same name. A conditional expression moves the choice to the right side of a single assignment, so the name appears once.

The form is value_if_true if condition else value_if_false. Python evaluates the condition first, then evaluates only the side it picked. The else part is required: shipping = 0.0 if order_total >= 100 is a SyntaxError, because an expression must produce a value in every case. Since the whole thing is an expression, it can sit anywhere a value can, such as on the right of = or inside print(). It also works after return.

The average line depends on Python evaluating only the chosen side. With count at 0 the condition is False, so total / count never runs and no ZeroDivisionError appears. The country line is the standard way to default a missing value: test is not None, and keep the real value whenever there is one.

A conditional expression binds more loosely than arithmetic and comparisons. In base + 5 if express else 0, Python takes all of base + 5 as the true side, so the result is either the whole sum or 0. To add 5 only for express orders, wrap the conditional in parentheses: base + (5 if express else 0).

Conditional expressions can chain: "gold" if spend >= 1000 else "silver" if spend >= 200 else "bronze" picks among 3 tiers, testing left to right. That is about the limit. A fourth tier, or an and inside a condition, turns the line into a puzzle, and an if/elif ladder assigning tier in each arm reads faster. Side effects fit badly too: print("a") if x else print("b") runs, but it is a statement wearing an expression's syntax.

A conditional most often lands inside a sum when the code computes a fee or a discount, and taxes hit the same problem. Either wrap it in parentheses, or compute it on its own line first: fee = 7.5 if order_total < 100 else 0.0, then total = order_total + fee. The second form leaves no precedence to reason about, each line holds a single decision, and a debugger shows fee as its own value. With order_total at 64.0, fee is 7.5 and total is 71.5; at 120.0, fee is 0.0 and total is 120.0.

Data that crosses a system boundary rarely arrives in a single shape. A quantity field decoded from a partner's JSON can be 12 or "12". It can also be None, or even True. The code receiving it has to decide what each shape means, and isinstance(value, int) is how a branch asks whether a value is an int.

isinstance(value, T) returns True when value is of type T or of a type built on top of T. The second half matters for one pairing in particular: bool is built on int, which is why True + 1 is 2 and isinstance(True, int) is True. The exact check type(value) is int accepts only int itself, so it says False for a bool.

That subtype rule is the classic hole in a quantity check. A test written as isinstance(qty, int) lets True through, and a boolean flag that leaked into the quantity column gets counted as 1. Test for bool before int, and reject it.

A type check belongs where mixed shapes enter your code. A single function receives the raw value, sorts it by type, and hands back either a clean int or None. Everything downstream works on that one type, so no other function needs to ask.

Each test in parse_qty is a type question, and their order matters for the reason guard order mattered earlier in this lesson: the bool test must come before the int test, or True would pass through as a quantity. A float such as 2.5 fails every test and reaches the final return None. int("12") converts a numeric string, while int("twelve") would stop the program with a ValueError, which the lesson on handling errors covers.

The warning sign is the same isinstance ladder appearing in a second and a third function. It means values were never normalized when they arrived. Every consumer then re-decides what "12" means, and sooner or later 2 copies decide differently. The fix is structural: convert once at the edge, and let everything after it assume a single type.

A second warning sign is a check that adds nothing. if isinstance(x, int) or isinstance(x, float): y = x + 1 branches on type to run an operation both types already support. Without the check, numbers behave the same. If None or "12" arrives, which should never happen, it fails loudly with a TypeError right where it's used.

The second capstone hinges on a habit worth keeping for any type ladder: feed it one value of every shape it could receive and note which test fires first. Give bools their own rows, since they are the values that slip into an int branch, and include 0, a real quantity that must come back as 0 and never as a missing value. Here is that check run on parse_qty from the animation.