Conditionals & Booleans

Before a program can decide, it needs something to decide on - and that something is a boolean, a value with exactly two states: True or False (capital T and F in Python; they are keywords, not strings). You rarely type True yourself. Instead you produce booleans by comparing things, and Python gives you six comparison operators that each answer a yes-or-no question:

area = 18
print(area >= 20)      # False  - is 18 at least 20?
print(area < 25)       # True
print(area == 18)      # True   - note: == compares, = assigns
print(area != 0)       # True   - not equal

The one that trips up every beginner is == versus =. A single = assigns a value (area = 18 puts 18 into area); a double == asks whether two things are equal and hands back a boolean. Mixing them up is one of the most common early errors, so read == in your head as the whole phrase 'is equal to'.

Comparisons work on more than numbers. Strings compare too - name == "kitchen" is True only when the text matches exactly, and Python is case-sensitive, so "Kitchen" == "kitchen" is False. Every one of these expressions collapses a real question about your design data into a single True or False, and that boolean is the fuel a conditional runs on.

A conditional wires a boolean to an action. The pattern reads almost like English:

area = 18

if area >= 20:
    tag = "large"
elif area >= 12:
    tag = "medium"
else:
    tag = "small"

print(tag)   # medium

Python checks each condition from the top. The first one that is True wins: its block runs, and every remaining branch is skipped. Here area >= 20 is False, so Python moves on; area >= 12 is True, so tag becomes "medium" and the else never even gets looked at. That top-to-bottom, first-match-wins behaviour is why order matters - if you tested >= 12 before >= 20, everything twelve or larger would be labelled medium and 'large' could never happen.

Three rules are worth fixing in your mind. First, only the if is required; elif (short for 'else if') and else are optional - you can have an if on its own, or an if with a single else, or a long chain of elifs. Second, else carries no condition; it is the catch-all that runs when nothing above matched. Third, you can chain as many elif branches as you need, which is how a script sorts rooms, budgets or materials into any number of categories with one clean structure.

In most languages, curly braces or keywords mark where a block of code begins and ends. Python uses indentation instead - the spaces at the start of a line are meaningful, not cosmetic. The lines indented under an if belong to that branch; when the indentation stops, the branch is over.

if area >= 20:
    tag = "large"
    print("needs two windows")   # still inside the if
print("done")                    # NOT inside - runs every time

The convention, followed everywhere, is four spaces per level. Do not mix tabs and spaces - Python will reject the file with an IndentationError, and this is one of the first errors every learner meets. The upside of this rule is real: Python code cannot look tidy while behaving otherwise, because the visual shape of the code is its logic. When you nest a conditional inside another (say, checking a room is large and then checking its orientation), each level steps in another four spaces, and the staircase of indentation shows you exactly how the decisions nest. Get in the habit now: let your editor insert four spaces on Tab, and treat the colon at the end of an if line as a promise that an indented block follows.

Nesting puts this to work. When one decision only makes sense inside another - a room is large, and then it faces west - the inner if sits inside the outer block, indented one more level, and its four extra spaces are a direct picture of the dependency:

if area >= 20:
    if facing == "west":
        print("large west room: add shading")

Read the depth of the indentation and you can see at a glance which decisions hang off which. That visual honesty is the quiet payoff of Python's rule: badly structured logic cannot hide behind tidy-looking braces, because here the shape on the page and the shape of the logic are one and the same thing.

Real design rules rarely hinge on a single fact. A room might need extra ventilation only if it is both large and a kitchen; a layout might be acceptable if it is either cheap or fast to build. Python expresses this with three plain-English operators - and, or, not - that combine booleans into bigger booleans:

area = 22
room = "kitchen"

if area >= 20 and room == "kitchen":
    print("large kitchen: add a second exhaust")

if room == "bath" or room == "utility":
    print("wet area: waterproof the floor")

if not room == "corridor":
    print("habitable space")

and is strict - the whole expression is True only when both sides are True. or is generous - True if either side is. not simply flips a boolean, turning True into False and back. There is also a subtler idea called truthiness: Python will treat many non-boolean values as True or False when you use them where a condition is expected. Zero, an empty string "", an empty list [], and the special value None all count as 'falsy'; almost everything else is 'truthy'. This lets you write natural checks like if rooms: to mean 'if the list has anything in it', or if not name: to mean 'if the name is missing or blank'. Used well, truthiness makes conditions read cleanly; used carelessly it hides bugs, so when you mean 'is this list empty', prefer the explicit if len(rooms) == 0: until the shorthand feels natural.

Once the basic shapes are comfortable, a few conditional patterns recur so often that they are worth learning by name. The first is the chained comparison, a piece of Python that reads exactly like mathematics. Where many languages force you to write area >= 12 and area < 20, Python lets you say it the natural way:

area = 15
if 12 <= area < 20:
    print("medium room")

This is not just shorter - it is clearer, and it says precisely what a designer means by 'between 12 and 20'. You can read 12 <= area < 20 aloud as 'twelve is at most the area, which is less than twenty', and the whole thing evaluates to a single boolean.

The second pattern is the guard clause: checking for the bad or special case first and dealing with it at once, rather than wrapping all your real logic inside a deeply nested if. Compare a nested style with a guarded one:

name = ""
if not name:
    print("skip: unnamed room")
else:
    print(f"processing {name}")

Guarding keeps the main logic flat and readable, and it pairs beautifully with the continue you will meet in loops - test for the case you want to skip, handle it, and move on. Deeply nested conditionals, by contrast, march further and further to the right and quickly become hard to follow; if you find yourself three or four levels deep, it is usually a sign to guard the exceptions early or to split the work into a function (Module 3).

The third is the conditional expression, often called the ternary - a way to choose between two values on a single line:

area = 18
tag = "large" if area >= 20 else "small"

Read it as 'large if the area is at least 20, otherwise small'. It is perfect for a simple two-way choice you want to assign to a variable, and it reads cleanly inside a list comprehension too. Do not stretch it to cover three or more cases - that is what the full if/elif/else chain is for, and forcing a many-way decision into a one-liner sacrifices exactly the readability that makes Python worth using. Reach for the ternary for genuine two-way choices, the chain for many-way ones, and a guard clause whenever a special case deserves handling up front. One last habit: never compare a boolean to True or False explicitly. Write if is_wet: and if not is_wet:, never if is_wet == True: - the comparison is redundant noise, since is_wet is already a boolean. Small as it is, dropping that habit is a mark of code that reads the way its author thinks.

Taken together, the conditional gives your scripts something close to judgement - not the deep judgement of design, which stays firmly yours, but the mechanical judgement of applying a rule the same way every single time. That reliability is the whole point. A tired designer misreads a schedule at the end of a long day; a conditional does not. Once you can express your rules as if/elif/else, you have handed the boring, error-prone half of decision-making to something that never gets bored, never skips a row, and never gets it wrong.