04Operators & expressions

In Chapter 3 we pinned names onto objects. In this one we make those objects do something. Here's the plan. Every scrap of code you write is an expression — a question Python answers by boiling it down to one value — and operators are the verbs that ask it. We'll add two song lengths and watch 200 + 245 collapse to 445. We'll split that total with /, //, and % to turn raw seconds into 7:25. We'll tell == apart from is, find the side of and Python never bothers to read, and flip raw bits with & | ^ ~ << >>. All the way through we keep asking the one thing that matters — when a line has more than one operator, who binds first? By the end you'll read any expression the exact way Python does, with precedence in hand and no magic left in it.

01An expression is a question; operators are the verbs

Let's start with the smallest useful thing you can ask. You've got two song lengths — 200 and 245 — and you want the total. Type 200 + 245, press Enter, and Python does exactly one thing. It answers. It keeps working until a single value is left standing — here, 445. That scrap of code that boils down to one value has a name: we'll call it an expression. Every expression shares that one job: collapse to a single answer. 200 + 245 is an expression. So is total // 60. So is a bare 445, because a value sitting alone is the smallest expression there is. The symbol doing the work is the operator — the verb of the sentence — and the values it grips are its operands. So 200 + 245 isn't really arithmetic homework. It's a tiny question — how long are these two songs, back to back? — and + is the verb that answers it.

Python ships seven arithmetic operators — + - * / // % ** — and most are familiar symbols in a slightly different form. Multiplication's × is typed * because no keyboard has a times sign. Division's ÷ becomes / for the same reason. ** is the power operator: 7 ** 3 means 7·7·7 = 343, not 7·3. That leaves two genuine strangers, // and % — both are kinds of division, and they're odd enough to get the whole next section to themselves. Point every one of the seven at the same pair of numbers and you get seven different answers. Drag the second number below and watch them diverge.

Now watch Python answer a stack of these questions in a row. Each print below hands a finished expression to the screen. Read the comment on each line as the answer Python works out.

# our playlist, in seconds — chapter 0's two anchors
blinding = 200                 # "Blinding Lights" — The Weeknd
titanium = 245                 # "Titanium" — David Guetta ft. Sia
total = blinding + titanium    # one + verb, two operands
print(total)                   # 445  — the whole playlist, once
print(total * 2)               # 890  — played twice, end to end
print(7 ** 3)                 # 343  — ** is power: 7·7·7, not 7·3

plays = 0
plays += 1                     # augmented assignment: read, add, rebind
print(plays)                   # 1

That last line hides the section's one real subtlety. += is augmented assignment, and for a number it means exactly three things: read plays, add 1, rebind plays to the result. Rebind is the exact word. An int is a photo, not a whiteboard (chapter 3), so += can never edit the 0 object itself. Python computes 0 + 1 and slides the name onto the answer. Here the answer isn't even freshly built: it's the 1 already waiting on chapter 3's small-integer shelf. Past the shelf — imagine 256 ticking to 257 — the result would be built anew. Either way plays lands on a different object than it started on: new value, new id(). That is the whole truth for numbers, and hold onto it, because it is about to matter. Point two names at one list and += does the opposite: it edits that very object in place and id() never moves, so a change made through one name quietly shows up under the other. That one difference is the seed of a whole class of aliasing bugs you'll hunt in chapter 6. The deeper cut below shows the split.

L = [200, 245]
before = id(L)
L += [230]         # grows the SAME list — before == id(L)
M = [200, 245]
M = M + [230]      # builds a NEW list — id(M) changes

Two of those seven verbs — // and % — are still just "divide," yet Python keeps them apart from / on purpose. One slash, two slashes, and the leftover: three ways to split a number, each answering a different question. →

02One slash, two slashes, and the leftover

"Blinding Lights" runs 200 seconds. Your music app shows 3:20. Those are the same fact in two forms, and getting from one to the other is exactly the gap between Python's three ways to divide. Learn these three symbols and you can turn any raw count into minutes-and-seconds, pages, rows, change owed, or the hour on a clock. They look nearly identical. They answer three genuinely different questions.

A single slash, /, is true division. It answers "exactly how many times?" and it has one unbreakable habit: it always hands back a float, a number carrying a decimal point. Not sometimes. Not only when it doesn't divide evenly. Even 6 / 3 comes back as 2.0, never a bare 2. One slash, always a float. Remember that, because it surprises everyone exactly once.

Two slashes, //, is floor division. It answers "how many whole times?" — do the division, then round down to a whole number. 200 // 60 is 3: three complete minutes have gone by, and it drops the sliver left over.

The percent sign, %, is the remainder (say it aloud as "mod"). It answers "what's left once the whole times are taken out?" 200 % 60 is 20: twenty spare seconds that couldn't fill another whole minute.

// and % are a matched pair — two halves of one act. One counts the full blocks; the other keeps the leftover. Together they account for every second and lose nothing: three minutes of sixty, plus twenty over, is two hundred again. That completeness isn't luck. In a moment you'll see Python guarantee it.

Watch Python compute all three. Nothing here is magic. Each line asks one of those three questions and prints the answer:

total = 200                     # "Blinding Lights", in seconds
print(total / 60)               # 3.3333333333333335  — exact ratio, a float
print(6 / 3)                    # 2.0  — still a float, even when it divides clean
print(total // 60)              # 3   — whole minutes only
print(total % 60)               # 20  — the seconds left over
print(divmod(total, 60))        # (3, 20)  — both answers in one call
print(f"{total // 60}:{total % 60:02d}")   # 3:20
print(f"{245 // 60}:{245 % 60:02d}")       # 4:05  — :02d pads the 5 into 05

Here's how those last two lines work. An f"…" string fills each {…} hole with the value of the expression inside it, so {total // 60} becomes 3. The :02d added to the second hole is a formatting instruction: "print this as a decimal integer, at least 2 digits wide, padding with a 0." That's what turns a lone 5 into 05, so "Titanium" reads as a proper 4:05 and not a broken 4:5.

So far, so tidy. But watch what "round down" really means the instant a number turns negative, because this is where half of all programmers slip. "Round down" does not mean "chop the decimals off." It means round toward negative infinity — always leftward on the number line, toward the smaller value. Slide the dividend below zero and watch // step down to the next multiple, never up toward zero.

Numbers answered with numbers. The next family of operators answers every question with just one of two words — and forces you to meet two subtly different notions of "equal": == and is. →

03Two kinds of equal: == and is

The comparison operators — == != < > <= >= — are a panel of yes/no judges. Each one asks a single question and always answers with a bool: True or False, never anything in the middle. Feed the panel 200 < 245 and it returns True. Feed it 245 == 245 and it returns True. There is no "sort of" and no "close enough." The verdict is one bit, the smallest answer a machine can give.

And Python is a strict judge: 7 == "7" is False. It will not quietly turn the string "7" into the number 7 to force a match. An int and a str are simply different kinds of thing, so the honest answer is "no, not equal." For the same reason 1 != "1" is True. Other languages fudge this; Python refuses to, and that refusal will save you from a whole class of silent bug.

What about comparing two strings — is "Avicii" "less than" "Daft Punk"? Yes, and it's decided the way a dictionary is ordered: character by character, by code point, the plain number behind each letter. ord('A') is 65 and ord('D') is 68. Python lines the two words up and looks at the very first pair — A versus D, 65 versus 68. The moment they differ, the match is settled. 65 < 68, so "Avicii" < "Daft Punk" is True, and not one of the remaining letters is ever read. By the same rule "Apple" > "Orange" is False, because the first characters, A (65) and O (79), decide it on the spot.

So far, so intuitive: == is asking "do these two things carry the same value?" But Python has a second, sharper question that looks almost the same and means something entirely different: is. And is is not a fancier ==. Where == asks "same value?", is asks "same object?" — literally the same thing in memory, the same identity id() handed you back in chapter 3. Two things can carry identical values yet be two separate objects. That gap is the whole lesson.

# three playlists, timed in seconds
a = [200, 245, 187]     # one list, built here
b = [200, 245, 187]     # a second list, same contents
c = a                   # NOT a new list — a second name for the first

print(a == b)           # True  — identical contents
print(a is b)           # False — two objects, two addresses
print(a is c)           # True  — one object wearing two labels

Here is where is gets dangerous, and where an interactive earns its keep. For small, common integers, CPython quietly keeps a single shared copy — one pre-built 200 that every 200 in your program points at (chapter 3's singleton trick). So two independently-computed 200s can turn out to be the same object — is says True — by pure caching accident. Push the number past the cached zone and the accident disappears: now they're two objects and is says False, even though == never wavered. Slide a song's length across the boundary and watch is flip.

== forces every value into a clean True or False. But Python will happily judge values that are neither — and the instant it knows the verdict, it stops reading. →

04Truthiness, and the logic that stops early

Type if playlist: and Python does something quietly generous: it does not demand a True or a False. It hands the question to the list itself and lets it answer. Every value in Python can stand in for a yes-or-no, and bool(x) shows the verdict it would give. Why would a language bother judging every value this way? Because the real questions you ask rarely arrive as tidy booleans. They arrive as "is the queue empty?" or "did the user actually type a name?" Python lets the queue and the string answer for themselves, so you never have to write len(name) > 0 when if name: says the same thing more plainly.

The rule that decides it fits on one line: empty or zero is falsy; everything else is truthy. That is the whole law. The complete falsy lineup is short enough to memorise — False, None, 0, 0.0, "", [], {}, set() — eight values, each one either a kind of nothing or a kind of zero. Every non-empty string, every non-zero number, and every collection with even a single thing inside is truthy.

Three operators combine these verdicts. not flips one: not x is True exactly when x is falsy. a and b is truthy only when both are; a or b when at least one is. But the headline of this section isn't what they compute — it's how. and and or are lazy. Python reads them strictly left to right and stops the instant the answer is settled. This is short-circuit evaluation. In False and anything, the anything is never touched, because a single falsy operand already doomed the and. In True or anything, same story: one truthy operand already saved the or.

That "jump clean over it" is not trivia — it's a guard you'll reach for constantly. Put a cheap, safe test on the left and let it decide whether the expensive or dangerous test on the right ever runs:

# the two canon tracks: "Blinding Lights" 200 s + "Titanium" 245 s
total, count = 445, 2
print(count != 0 and total / count > 180)   # True  — the average is 222.5 s

count = 0                                # now the playlist is empty
print(count != 0 and total / count > 180)   # False — total / count NEVER runs

When count is 0, the left side count != 0 is False, so the whole and is already decided and total / count — the division-by-zero that would crash your program — is never reached. The dangerous half sits right there in the source and simply doesn't run. Reverse the two halves and the identical program crashes with ZeroDivisionError. Order is the whole design. Drag the slider below and watch the left operand act as a gate for the right one.

and, or and not weigh a value as a single whole — one verdict for the entire thing. But chapter 0 promised operators that reach inside a number and grip its switches one at a time. Down to the bits, with & | ^ ~ << >> →

05Down to the bits: & | ^ ~ << >>

Chapter 0 taught you the secret every int is hiding: it isn't really a number, it's a row of switches. 12 is the pattern 1100; 10 is 1010. Every operator you've met so far — +, *, == — treats that row as a quantity and does arithmetic on the whole thing. Six new operators work differently. They reach straight past the number and grab the switches themselves, one column at a time. Here they are: & (AND), | (OR), ^ (XOR), ~ (NOT), and the two shifts << and >> that slide the whole row sideways.

The first three work by laying one number on top of the other and reading down each column. Stack 12 over 10 and ask a yes/no question of each pair of bits. & keeps a 1 only where both switches are on → 1000, which is 8. | keeps a 1 where at least one is on → 1110, which is 14. ^ — "exclusive or" — keeps a 1 only where exactly one is on, the two switches disagreeing → 0110, which is 6. No carrying, no borrowing, no place value spilling into the next column. Just eight small votes, tallied straight down.

One diagram only shows one operator, so here's the same machine with a dial on it. Set two four-bit numbers and pick which question to ask each column. Watch the bottom row light up, and notice that changing a's 8-bit never disturbs a's 1-bit's answer. The columns are independent.

The last two operators don't combine two numbers at all — they take one number and slide its whole row of switches sideways. x << 1 shoves every bit one place to the left and feeds a fresh 0 in on the right; x >> 1 shoves everything right and lets the low bit fall off the edge into oblivion. You already know this move in base ten: appending a 0 to 34 makes 340, ten times bigger; chopping the last digit makes 3. Same trick, base two — so a left shift doubles and a right shift halves. 5 << 2 is 5 × 4 = 20; 200 >> 1 is 100, the length of "Blinding Lights" cut in half. One catch worth its own breath: because the low bit simply drops off, >> always rounds down. 201 >> 1 is not 100.5 — it's 100, the same floor as 201 // 2.

That leaves ~, the loner — it takes a single number and flips every switch, 1↔0. Flip the bits of 12 = 1100 and you'd swear the answer is 0011 = 3. Run it and Python says ~12 is -13. What? The trick is a thing chapter 0 whispered and this operator shouts: a Python int doesn't stop at the four bits you can see. It carries an endless train of leading zeros off to the left — …0000 1100 — and ~ flips every last one of them into a 1. An endless run of leading ones is precisely how binary writes a negative number, and the result lands, without fail, on ~x == -x - 1.

Step back and notice what none of these six operators did: none of them built anything. No new container was allocated, no list copied, no object cloned. Each result is just another int, assembled from switches the operands were already holding. At the level of the metal, &, |, ^, and the shifts are each a single CPU instruction — one tick of the clock, no loop, no memory hunt. That's why, in the machine, bitwise work is about the cheapest thing a processor can do.

# six operators that reach past the number, down to its switches
print(12 & 10)      # 8   1100 AND 1010 = 1000  (keep where BOTH are 1)
print(12 | 10)      # 14  1100 OR  1010 = 1110  (keep where EITHER is 1)
print(12 ^ 10)      # 6   1100 XOR 1010 = 0110  (keep where EXACTLY one is 1)
print(5 << 2)       # 20  slide left 2  -> x 4
print(200 >> 1)     # 100 slide right 1 -> half of "Blinding Lights"
print(~12)          # -13 flip every bit: ~x == -x - 1

You now command a dozen-plus operators, and nothing stops you from stacking five of them in one breathless line: 1 | 2 ^ 1 & 3. Python answers 3 — but why that, and not something else? A new question has appeared: when operators collide, who binds first? →

06Who binds first: precedence

Type 2 + 3 * 4 and Python answers 14, not 20, and it is not being clever or careless. It is obeying a fixed pecking order: * outranks +, so the multiplication gets wrapped in invisible parentheses and settled first, as if you had written 2 + (3 * 4). Every operator you met in this chapter carries a rank — its precedence — and before a single value is computed, Python uses those ranks to decide the shape of the expression: who groups with whom. Get the shape right and the answer falls out for free.

That shape is a ladder, and Python consults the exact same ladder every time. The good news is you do not memorise all thirteen rungs. You memorise two things: the rough shape — arithmetic binds tighter than bitwise, which binds tighter than comparisons, which bind tighter than the words and/or — and the three surprises that trip up everyone who guessed. For everything else, reach for a pair of parentheses and stop worrying.

Surprise one lives at the top. ** outranks the unary minus, so -2 ** 2 reads as -(2 ** 2) = -4, not (-2) ** 2 = 4. The minus ranks below the power. Surprise two is the one that ends an old argument: the whole bitwise family — &, ^, | — sits above the comparisons, so in x == 1 | y == 2 the | grabs its neighbours before either == does. It is the final nail in the "| is just a fancier or" myth: | is nothing of the sort. Surprise three lives at the bottom: not beats and beats or, so True or False and False is True — the and runs inside the or, giving True or (False and False).

print(2 + 3 * 4)                 # 14  — * binds before +
print((2 + 3) * 4)               # 20  — parentheses rewrite the tree
print(-2 ** 2)                   # -4  — ** binds before unary minus
print(2 ** 3 ** 2)                # 512 — ** groups right-to-left
print(True or False and False)   # True — and binds before or

Reading the ladder is one thing; watching a real line collapse down it is another. Below is a genuine expression built from the playlist — is "Blinding Lights" (200 s) worth keeping? — and it packs six operators across four families. Drag the step control and watch Python fold it up one rung at a time, tightest first. The gold band shows which sub-expression binds at each step; the bottom line is the whole expression after that fold.

An expression computes a value — but it never decides anything. Staple a decision onto it — if seconds > 180: — and the very same ladder you just learned suddenly steers which lines run at all. That is where your code starts to branch, loop, and react: the Control flow chapter →