Python Keywords

Keywords are reserved words with fixed meaning in Python's grammar — they form the language's syntax, so you can't use them as variable, function, or class names. They're case-sensitive (True, not true), and you can list them at runtime with import keyword; keyword.kwlist.

They fall into rough groups:

• Control flow: if, elif, else, for, while, break, continue, pass, match/case (soft keywords, 3.10).
• Functions/classes: def, return, lambda, class, yield.
• Logic/identity: and, or, not, in, is.
• Exceptions: try, except, finally, raise, assert.
• Scope/imports: import, from, as, global, nonlocal.
• Async: async, await. Values: True, False, None.

if x > 0 and x is not None:
    for item in items:
        ...

Follow-ups to expect:

• Soft keywords (match, case, type, _) are contextual — they're only keywords in their specific syntax, so they can still be used as identifiers elsewhere (though it's discouraged).
• is vs ==: is (identity) compares object identity; == compares value — a classic source of bugs, use is only for None/singletons.
• A trailing-underscore name (class_, type_) is the PEP 8 way to work around a keyword clash.

return exits a function immediately and hands a value back to the caller. Execution of the function stops at that point — any code after it doesn't run — and the returned value becomes the result of the call.

def divide(a: float, b: float) -> float | None:
    if b == 0:
        return None        # early exit
    return a / b           # normal result

Follow-ups interviewers like:

• No return, or a bare return returns None implicitly — so x = mylist.sort() gives None, a classic bug since in-place methods return None.
• Returning multiple values actually returns one tuple, unpacked at the call site: return x, y then a, b = f().
• return vs yield: return ends the call; yield suspends it and makes the function a generator that resumes later.
• return vs print: print only shows text; return gives a value the program can use. Beginners often confuse the two.
• return in try/finally: a finally block still runs after the return is evaluated, and a return in finally will override the one in try — a known gotcha.

if runs a block only when a condition is truthy, optionally with elif for further tests and else for the fallback. The colon opens the block and the body is indented:

if score >= 90:
    grade = "A"
elif score >= 80:
    grade = "B"
else:
    grade = "C"

Follow-ups interviewers probe:

• Truthiness: the condition need not be a real bool. Empty containers ([], {}, ""), 0, and None are falsy; non-empty/non-zero values are truthy. So if items: is the idiomatic "is this list non-empty?" — prefer it over if len(items) > 0:.
• is vs == in conditions: use if x is None:, not if x == None:.
• Conditional (ternary) expression: grade = "A" if score >= 90 else "B" for a one-line value choice.
• The walrus operator lets you test and capture in one go: if (n := len(data)) > 10:.
• For many discrete cases against one value, match/case (3.10) can be cleaner than a long elif chain — though if/elif remains the default for boolean conditions.
• There's no switch statement; match is the structural-pattern equivalent.

for iterates over the items of any iterable — list, tuple, string, dict, set, range, generator, file — running the body once per item. Python's for is a "for-each" loop, not a C-style counter loop:

for item in [10, 20, 30]:
    print(item)

Follow-ups interviewers expect:

• range() for counts: for i in range(5): when you actually need indices; range is a lazy sequence, not a list.
• enumerate when you need index and value: for i, x in enumerate(items): — cleaner than range(len(items)).
• zip to iterate two sequences in parallel: for name, age in zip(names, ages):.
• Iterating a dict yields its keys by default; use .items() for key/value pairs, .values() for values.
• for/else: the else block runs only if the loop finished without hitting break — useful for search loops, and a frequent gotcha.
• Don't mutate a list while iterating it (e.g. removing items) — iterate over a copy or build a new list/comprehension instead.
• Under the hood, for calls iter() then next() until StopIteration — the iterator protocol.

try/except is Python's exception-handling construct: code that might fail goes in the try block; if an exception is raised, control jumps to a matching except block instead of crashing. The full form adds else and finally:

try:
    value = int(user_input)
except ValueError as err:
    print(f"not a number: {err}")
else:
    print("parsed", value)   # runs only if no exception
finally:
    print("always runs")     # cleanup, runs no matter what

Follow-ups interviewers expect:

• Catch specific exceptions, not a bare except: — a bare clause also swallows KeyboardInterrupt/SystemExit and hides bugs. Catch the narrowest type, or except Exception at most.
• Multiple types: except (ValueError, TypeError) as err:; multiple except blocks are tried top to bottom, so order specific before general.
• else vs putting code in try: else runs only when no exception fired and keeps the "risky" lines minimal.
• finally always runs (even on return or re-raise) — for cleanup; though a context manager (with) is usually cleaner for resources like files.
• Re-raising and chaining: bare raise re-throws; raise NewError(...) from err preserves the cause.
• Exception groups and except* (3.11) handle several errors at once, common with async code.
• Don't use exceptions for ordinary control flow — "EAFP" is fine, but catching everything to ignore it is a smell.