06 — Strings & Text

Answer: A — Hello, World

Explanation: Strings are immutable in Python. .replace() (like .upper(), .strip(), .lower(), and every other "modifying" string method) does not change s in place — it computes and returns a brand-new string object. Because the return value here is never assigned back to s, the original variable still points at the untouched "Hello, World". Option B is the tempting mistake of assuming methods mutate the receiver, as they do for lists. There's no item assignment happening (C), and .replace() returns a string, never None (D) — only a handful of in-place methods like list.sort() return None.

Answer: B — " " (the three spaces, unchanged)

Explanation: name.strip() returns a new stripped string, but that result is discarded — the local variable name still refers to the original three-space string. len(name) is therefore 3, not 0, so the "empty" branch never runs and the untrimmed spaces are returned as if they were a valid username. This is the single most common beginner bug with immutable strings: the fix is name = name.strip(). Nothing here raises an error (D), and it never reaches "" (C) because that would require reassignment first.

Answer: C — LOG: world then Hello, WORLD!

Explanation: An f-string's {} can hold any valid Python expression, including function calls, and that expression is evaluated immediately, right where the f-string is written — before the surrounding string is even finished being built. So log(name) runs first: it prints LOG: world (using the original lowercase name) and then returns "WORLD". Only after that does the f-string finish assembling "Hello, WORLD!", which the second print then outputs. Option B is wrong because log prints msg (still lowercase) before it uppercases anything.

Answer: D — count=42, len(items)=2

Explanation: Python 3.8+ supports the = debug specifier: writing {expr=} inside an f-string expands to the literal source text of expr, an =, and the value's repr — all in one go. So {count=} becomes count=42 and {len(items)=} becomes len(items)=2, without you having to type the variable name twice. It's not a syntax error (C) — this has been valid since 3.8 — and it doesn't silently drop the expression text (B) or the value (A); it shows both.

Answer: A — $20.00

Explanation: The .2f format spec rounds to 2 decimal places using round-half-to-even on the underlying binary value, it does not truncate. 19.999 rounded to two decimals is 20.00: the third decimal digit (9) rounds the second decimal up from 9 to 10, which carries into the whole-number part. Option B is the truncation mistake a beginner might expect; .2f never just chops digits off.

Answer: B — ID: 000 (label right-aligned in a width-5 field, index zero-padded to 3 digits)

Explanation: {label:>5} right-aligns "ID" (2 characters) inside a minimum field width of 5, padding with 3 leading spaces. {i:03d} formats the integer with zero-padding to a minimum of 3 digits, so 0 becomes 000. Together that produces " ID: 000". Left-alignment (<, option A) would put the padding after ID, not before it, and no error is raised — > and 03d are both standard, well-formed format specs.

Answer: C — 1,234,567 then 1_234_567

Explanation: The format spec mini-language supports , and _ as thousands-separator options for numeric types — , inserts commas, _ inserts underscores, both grouping digits in threes. They're independent options, so the two print calls produce different separators, not the same one twice (B). This is unrelated to numeric literals like 1_000 in source code; here _ is purely a display-formatting choice.

Answer: D — Hello, Alice then Hello, Bob

Explanation: An f-string is evaluated eagerly, at the exact point it's written — f"Hello, {name}" bakes in whatever name is inside the function right then ("Alice"), producing a fixed, already-finished string. It cannot be "replayed" later with a different value. The plain string "Hello, {name}" (no f prefix) is just literal text containing {name} — nothing is substituted until something later calls .format(name=...) on it, using whatever value is passed in at that call site, which by then is the outer, reassigned "Bob". This is the key practical difference between f-strings (eager) and .format() templates (lazy, reusable).

Answer: B — TypeError: can't concat str to bytes

Explanation: In Python 3, str (text) and bytes (raw binary data) are distinct, incompatible types with no implicit conversion between them — unlike Python 2, where str and byte strings mixed freely. + between a bytes object and a str object raises TypeError immediately; there is no silent auto-encoding (D). To combine them you must be explicit: data + "ok".encode() (or data.decode() + "ok"), choosing the encoding yourself rather than relying on a guess.

Answer: C — UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 3

Explanation: The ASCII codec can only represent code points 0–127. é (U+00E9) is outside that range, so .encode("ascii") raises UnicodeEncodeError at the first offending character it hits — it does not silently strip accents (B) or fall back to UTF-8 bytes (A). It's specifically an encode error, not decode (D), because the operation is going from str to bytes; decode errors happen in the opposite direction. To actually get bytes out of this string, use an encoding that covers the characters (.encode("utf-8")) or pass errors="ignore"/"replace" if lossy output is acceptable.

Answer: D — open() with no encoding= argument uses the platform's default text encoding (often cp1252 on Windows vs. UTF-8 on macOS/Linux), not the file's actual encoding

Explanation: When encoding= is omitted, Python falls back to locale.getpreferredencoding(), which depends on the OS and locale settings — commonly UTF-8 on macOS/Linux but historically cp1252 (or another codepage) on Windows. The file's bytes never change between machines; only the assumed encoding used to decode them does, and cp1252 doesn't define every byte value, so certain UTF-8 multi-byte sequences trigger a decode error there that never surfaces on a UTF-8-default system. The fix is to always pass open(path, encoding="utf-8") explicitly so behavior is identical everywhere.

Answer: A — True, False

Explanation: in means something different depending on the container. Against a str, it tests substring containment at any position, so "ERROR" in log_line is True because that exact sequence of characters occurs in the text. Against a list, in tests exact element membership — it does not search inside each element's characters — so "ERR" in levels is False, even though "ERR" happens to be a substring of the list's "ERROR" entry. Conflating these two behaviors is a common source of silent logic bugs.

Answer: B — '----------' '' ''

Explanation: str * int repeats the string that many times. A multiplier of 0 produces an empty string, and — this is the gotcha — so does any negative multiplier: Python silently clamps negative repeat counts down to 0 rather than raising an error. There's no exception for either case (ruling out A and D), and "x" * 0 is '', not 'x' (C).

Answer: C — nohtyp thon ''

Explanation: s[::-1] with a step of -1 reverses the whole string, giving "nohtyp". Slicing is far more forgiving than direct indexing: out-of-range start/stop bounds are silently clamped rather than raising. s[2:100] clamps the stop to the string's actual length and returns everything from index 2 onward, "thon". s[50:60] starts past the end of the string entirely, so it returns an empty string '' — not an error. Contrast this with s[50], which would raise IndexError; slicing and indexing have different bounds-checking rules, and forgetting that can hide real off-by-one bugs.

Answer: D — A garbled, multi-line result — \n becomes a newline and \t becomes a tab, so it prints as C: on one line, ew_folder on the next, then a tab before est

Explanation: In an ordinary string literal, backslashes introduce escape sequences. \n inside "...C:\new_folder..." is not "backslash then n" — it's interpreted as an actual newline character, and \t in \test becomes an actual tab character. The path is silently corrupted with no error raised (ruling out B and C), which is far more dangerous than a crash because it can go unnoticed. The fix is a raw string, r"C:\new_folder\test", which tells Python to treat every backslash as a literal character — essential for Windows paths and regex patterns, where backslashes are meaningful on their own.

Answer: A — True True / True False

Explanation: == always compares by value, so all four comparisons of content agree — both pairs hold equal text, hence True for both == checks. is compares object identity, which is a different question. a and b are two identical string literals appearing in the same compiled code; CPython's compiler commonly folds equal literals into one shared object as an implementation detail, so a is b often comes out True — but this is not guaranteed by the language spec, only an optimization. c is built at runtime via "".join(...), producing a genuinely new object even though its contents match, so a is c is False. The takeaway: never rely on is for string equality — always use ==.

Answer: D — " 3.14" (right-aligned in a field of width 10)

Explanation: Format specs can themselves contain nested replacement fields — {width} and {precision} inside the outer spec are evaluated first, producing the equivalent of {value:10.2f} at runtime, so width and precision can be computed dynamically instead of hardcoded. 3.14 is 4 characters, so a minimum width of 10 adds 6 leading spaces. Numeric types default to right-alignment when a minimum width is specified — unlike strings, which default to left-alignment — so the padding goes before the digits, not after (ruling out A).