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 & | ^ ~ << >>. And the whole way through we keep asking the one thing that actually 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, precedence in hand, with no magic left anywhere 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 watch what Python does with it. It does exactly one thing: it answers. It keeps chewing 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, and every expression alive 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 old friends in a keyboard costume. 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 flavours of division, odd enough that they 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.

Enough talk. 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 precisely three things: read plays, add 1, rebind plays to the result. And 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 that 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 constructed 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 silently shows up under the other. That single divergence is the seed of a whole class of aliasing bugs you'll hunt in chapter 6. The deeper cut below shows the split.

you type
blinding, titanium = 200, 245
print(blinding + titanium, titanium - blinding)
print(blinding * 2, blinding / 3)
print(titanium // 60, titanium % 60, 2 ** 10)

plays = 0
plays += 1                  # read 0, add 1, rebind
plays *= 5                  # every binary verb has an augmented twin
print(plays, -plays)

print("-" * 20)             # the same * verb, a different type
print(7 + 2.0, type(7 + 2.0))

you see
445 45
400 66.66666666666667
4 5 1024
5 -5
--------------------
9.0 <class 'float'>

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. →

you type
print((n := 5) + 1)         # bind n AND hand the 5 straight back
print(n)                    # the name survives the expression

title = "Blinding Lights"
print("long" if (size := len(title)) > 12 else "short", size)

length = len(title)         # the plain two-line version
print("long" if length > 12 else "short", length)

you see
6
5
long 15
long 15

02One slash, two slashes, and the leftover

"Blinding Lights" runs 200 seconds. Your music app shows 3:20. Those are the same fact wearing two outfits — and the wardrobe change 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, 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. Burn that in, 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 shrugs off the sliver left dangling.

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 crumbs. Together they account for every second, spilling 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 say all three out loud. Nothing here is magic; each line just 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

Decoder for those last two lines: an f"…" string fills each {…} hole with the value of the expression inside it, so {total // 60} becomes 3. The :02d tacked onto 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 promotes a lonely 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 the trapdoor half of all programmers step through. "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, and 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," 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 genus 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.

you type
seconds = 200
titles = ["Blinding Lights", "Titanium"]

print(seconds == 200, seconds != 245, seconds < 245)
print(180 <= seconds <= 240)              # one chain, seconds read once
print("Titanium" in titles, "Levels" not in titles)
print("ani" in "Titanium")                # a str tests substrings
encore = None
print(encore is None, encore is not None)

you see
True True True
True
True True
True
True False

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?" It means 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 turns treacherous, 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, and is says True, by pure caching accident. Push the number past the cached zone and the accident evaporates. Now they're two objects and is says False, even though == never wavered. Slide a song's length across the boundary and watch is betray you.

== 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. →

you type
seconds = 245
label = "long" if seconds > 240 else "standard"
print(label)

n = 1
print(f"{n} song{'s' if n != 1 else ''} queued")

grade = "A" if 180 <= seconds <= 240 else "B" if 120 <= seconds <= 300 else "C"
print(grade)

you see
long
1 song queued
B

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) reveals 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, and 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, every collection with even a single thing inside: truthy.

# THE ORIGINAL -- four lines to choose between two words
seconds = 245

if seconds > 240:
    label = "long"
else:
    label = "standard"
print(label)                             # long

# THE REWRITE -- the same decision, as one expression
label = "long" if seconds > 240 else "standard"
print(label)                             # long
# WHY: the ternary IS an expression, so it can sit on the right of an =.
#      Read it aloud: "long, if seconds > 240, otherwise standard."

# THE DEFAULT -- the same shape, twice shorter each time
title = ""

if title:
    shown = title
else:
    shown = "Untitled"
print(shown)                             # Untitled

shown = title if title else "Untitled"   # the ternary version
shown = title or "Untitled"              # or does it in three words
print(shown)                             # Untitled

# AND THE ONE YOU MUST NOT REWRITE ----------------------------
downloaded, explicit = False, True

if not downloaded:                       # two side effects on this branch
    print("fetching", seconds, "seconds of audio")
    print("marking explicit:", explicit)
else:
    print("already on the device")
# WHY: a ternary must pick a VALUE. These branches do work instead --
#      two statements on one side, none of them producing anything.

# Squeeze it in anyway and you get a line nobody wants to inherit:
print("fetching") if not downloaded else print("already on the device")
# It runs, it prints, and its own value is None -- an if-statement
# wearing an expression's coat. Leave it as the if.

Three operators braid these verdicts together. 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 whole 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.

you type
typed = ""
print(typed or "guest")           # "" is falsy, so or hands back the right side
print("Ajai" or "guest")          # truthy left, handed back untouched
print(0 and 1 / 0)                # falsy left settles it: the division never runs
print(245 and 200)                # both truthy: and hands back the LAST one
print(type(245 and 200))
print(not "", not "0")            # only not always returns a real bool

you see
guest
Ajai
0
200
<class 'int'>
True False

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 gets to run:

# 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. That means 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 execute. Reverse the two halves and the identical program explodes with ZeroDivisionError. Order is the whole design. Drag the slider below and watch the left operand act as a gate for the right one.

>>> title = "Titanium"   # a title that is NEITHER of the two we test for
>>> title == "Blinding Lights" or "Levels"
>>> bool(title == "Blinding Lights" or "Levels")
>>> title in ("Blinding Lights", "Levels")

'Levels'
True
False

# defaults.py  --  what the user left blank, filled in by `or`

# three answers exactly as input() hands them back: always strings
typed_name   = ""        # they just pressed Enter
typed_repeat = "3"       # they typed 3
typed_note   = "0"       # careful: a real answer that only LOOKS empty

name   = typed_name or "guest"          # "" is falsy -> the default wins
repeat = int(typed_repeat or "1")       # the default is a string too
note   = typed_note or "(none)"         # "0" is one character, so it stays

print("welcome,", name)
print("playing the set", repeat, "times")
print("note:", note)

# the guard: the cheap test on the left protects the risky one on the right
total, count = 445, 0
average = count != 0 and total / count
print("average:", average)

# and the trap `or` sets for you: it cannot tell blank from a real zero
plays = 0
print("plays:", plays or "never played")                     # wrong for a real 0
print("plays:", plays if plays is not None else "unknown")   # says what you mean

welcome, guest
playing the set 3 times
note: 0
average: False
plays: never played
plays: 0

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 & | ^ ~ << >> →

# ONE EXPRESSION, FOUR YEARS ----------------------------------
year = 2024
print(year, year % 4 == 0 and (year % 100 != 0 or year % 400 == 0))   # 2024 True

year = 1900
print(year, year % 4 == 0 and (year % 100 != 0 or year % 400 == 0))   # 1900 False

year = 2000
print(year, year % 4 == 0 and (year % 100 != 0 or year % 400 == 0))   # 2000 True

year = 2023
print(year, year % 4 == 0 and (year % 100 != 0 or year % 400 == 0))   # 2023 False

# HOW TO READ IT
#   year % 4 == 0            divisible by 4 -- the ordinary leap year
#   year % 100 != 0          ...unless it is a century year
#   year % 400 == 0          ...unless that century divides by 400
# The chain is "divisible by 4 AND (not a century OR a 400-year century)".
#
# ON THE PARENTHESES: and binds tighter than or, so dropping them gives
#   (year % 4 == 0 and year % 100 != 0) or year % 400 == 0
# which happens to agree on every real year -- any year divisible by 400
# is divisible by 4 too, so the left side can never be wrongly rescued.
# Keep the parentheses anyway. They state the rule you meant, and the
# next reader should not have to prove that coincidence to themselves.

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, and 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 are ruder than that. They reach straight past the number and grab the switches themselves, one column at a time. Meet them: & (AND), | (OR), ^ (XOR), ~ (NOT), and the two shifts << and >> that slide the whole row sideways.

The first three work exactly like 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 little 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 strangers.

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, and chopping the last digit makes 3. Same trick in base two, so a left shift doubles and a right shift halves. 5 << 2 is 5 × 4 = 20, and 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.

Traceback (most recent call last):
  File "check_length.py", line 4, in <module>
    if seconds < 180:
       ^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'str' and 'int'

Traceback (most recent call last):
  File "banner.py", line 4, in <module>
    print("=" * (width / 2))
          ~~~~^~~~~~~~~~~~~
TypeError: can't multiply sequence by non-int of type 'float'

Traceback (most recent call last):
  File "trim.py", line 4, in <module>
    short = title - "ium"
            ~~~~~~^~~~~~~
TypeError: unsupported operand type(s) for -: 'str' and 'str'

you type
a, b = 12, 10
print(a & b, a | b, a ^ b, ~a)

print(5 << 1, 5 << 3, 200 >> 1, 201 >> 1)
print(bin(200), int("11001000", 2))

EXPLICIT, DOWNLOADED, LOVED = 1, 2, 4
state = EXPLICIT | LOVED                  # set two switches
state &= ~EXPLICIT                        # clear one
print(state, bin(state), bool(state & LOVED), bool(state & DOWNLOADED))

you see
8 14 6 -13
10 40 100 100
0b11001000 200
4 0b100 True False

# 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. Nail the shape 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. First, the rough shape: arithmetic binds tighter than bitwise, which binds tighter than comparisons, which bind tighter than the words and/or. Second, the three surprises that trip up everyone who guessed. Everything else, you reach for a pair of parentheses and stop worrying.

you type
print(200 + 45 // 2, (200 + 45) // 2)     # // outranks +
print(5 << 1 + 1, (5 << 1) + 1)           # + outranks <<
print(0 or 200 and 245)                   # and outranks or
print(1 == 1 | 3 == 3)                    # | dives under both ==
print("long" if 245 > 240 else "short")   # the ternary binds loosest of all

you see
222 122
20 11
245
False
long

Surprise one lives at the top. ** outranks the unary minus, so -2 ** 2 reads as -(2 ** 2) = -4, not (-2) ** 2 = 4. The minus is a smaller fish than 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.

# CASE A ------------------------------------------------------
print(200 + 45 // 2)          # 222
print((200 + 45) // 2)        # 122
# WHY: // sits on a higher rung than +, so it grabs the 45 and the 2
#      first: 200 + (45 // 2) -> 200 + 22. Parentheses rewrite the tree.

# CASE B ------------------------------------------------------
a, b = 1, 3
print(a == 1 | b == 3)        # False
print((a == 1) | (b == 3))    # True
# WHY: | binds TIGHTER than ==, so 1 | b runs first and gives 3.
#      What is left is a run of comparisons -- a == 3 == 3 -- which
#      Python chains into (a == 3) and (3 == 3): False.
#      This is the whole reason "| is just a fancier or" is a myth.

# CASE C ------------------------------------------------------
print(200 or 0 and 245)       # 200
print((200 or 0) and 245)     # 245
# WHY: and outranks or, so line one is 200 or (0 and 245). The left
#      operand is truthy, so or hands 200 straight back and the right
#      half never runs at all. Parenthesise and the or settles first,
#      handing 200 on to the and -- which then returns its last operand.

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 →

# label.py  --  three verdicts per song, and not one if-statement

title, seconds = "Blinding Lights", 200

radio  = 120 <= seconds <= 240
length = "short" if seconds < 120 else "standard" if seconds <= 240 else "long"
grade  = "A" if 180 <= seconds <= 240 else "B" if 120 <= seconds <= 300 else "C"
print(f"{title:<16}{seconds:>4}s  {length:<9} grade {grade}  radio={radio}")

title, seconds = "Titanium", 245

radio  = 120 <= seconds <= 240
length = "short" if seconds < 120 else "standard" if seconds <= 240 else "long"
grade  = "A" if 180 <= seconds <= 240 else "B" if 120 <= seconds <= 300 else "C"
print(f"{title:<16}{seconds:>4}s  {length:<9} grade {grade}  radio={radio}")

title, seconds = "Intro (Skit)", 42

radio  = 120 <= seconds <= 240
length = "short" if seconds < 120 else "standard" if seconds <= 240 else "long"
grade  = "A" if 180 <= seconds <= 240 else "B" if 120 <= seconds <= 300 else "C"
print(f"{title:<16}{seconds:>4}s  {length:<9} grade {grade}  radio={radio}")

Blinding Lights  200s  standard  grade A  radio=True
Titanium         245s  long      grade B  radio=False
Intro (Skit)      42s  short     grade C  radio=False