Control Flow, Loops, Lists and Logic practice questions

range(0,11)

Why it fails: Includes 0, which is unnecessary but still sums to 55; however the question says the loop includes 0 and that's not desired.

range(0,101)

Why it fails: Generates 0..100, sum 5050

range(1,10)

Why it fails: Generates 1..9, sum 45

for item in mylist: item = item.upper()

Why it fails: Incorrect: assigns uppercase to item but never prints.

for item in mylist: print(item.upper)

Why it fails: Incorrect: missing parentheses, prints method object, not string.

[item for item in items if item.isdigit()]

Why it fails: Incorrect because `isdigit()` is a string method that returns True only if the string consists of digits. It is not suitable for filtering all strings.

[item for item in items if type(item) is 'str']

Why it fails: Incorrect because `type(item) is 'str'` compares the type object to a string literal, which is not valid. The correct comparison would be `type(item) is str`.

[item for item in items if type(item) == str]

Why it fails: Incorrect because although `type(item) == str` works for basic strings, it is not the recommended approach; `isinstance` is preferred for type checking in Python.

True in flags

Why it fails: This checks membership using the `in` operator. For a list of booleans, it works, but it only looks for the exact boolean value `True`, not for general truthy values. It is not the recommended way to check if any element is true.

all(flags)

Why it fails: all(flags) returns True only when every element is True, so it fails the 'at least one' requirement; any(flags) is the correct built-in. It is tempting because all() and any() share identical syntax and both reduce a boolean iterable to a single result.

flags.any()

Why it fails: `flags.any()` is not a valid Python method for lists; it exists in libraries like NumPy but not in standard Python.

No output

Why it fails: Prints for i=0,1,2,4.

0 1 2 3 4

Why it fails: Continue skips 3.

0 1 2 4 5

Why it fails: Range ends at 4.

False

Why it fails: Port 80 is still in the list.

None

Why it fails: Function returns a boolean.

Error

Why it fails: No error.

Rewrite as: [line for line in lines if 'ERROR' in line]

Why it fails: Returns the whole line, not just message.

Change the list to a dictionary

Why it fails: Unnecessary.

Swap the order of the for clauses to: [msg for line in lines for timestamp, msg in line.split(': ') if 'ERROR' in msg]

Why it fails: Still crashes because line.split(': ') returns list, not unpackable.

ValueError: Raised when an operation or function is applied to an object of inappropriate type

Why it fails: Incorrect — this describes TypeError, not ValueError.

IndexError: Raised when a dictionary key is not found

Why it fails: Incorrect — this describes KeyError, not IndexError.

Module: A collection of modules organized in a directory tree

Why it fails: Incorrect — this definition describes a package, not a module.

Package: A file containing Python definitions and statements

Why it fails: Incorrect — this definition describes a module, not a package.

for score in scores: if score == 100: pass ...

Why it fails: pass does nothing, so the loop continues past the 100 score and processes every remaining element, failing the stop requirement; break is needed instead. pass is tempting as a placeholder when a branch is intentionally empty, which suits stubs or deliberately ignored cases during development.

for i in range(len(scores)): if scores[i] == 100: exit() ...

Why it fails: exit() terminates the entire interpreter, not merely the loop, so any code after the loop never runs; break is the correct construct. Index-based iteration is tempting because it gives access to positions, which suits scenarios needing the index alongside the value, such as in-place list modification.

while scores: score = scores.pop(); if score == 100: continue ...

Why it fails: Using continue skips the perfect score but keeps iterating, so processing never stops at 100 as the requirement demands; break is needed. Popping from a list is tempting because it consumes items one at a time, which suits destructive queue-style processing where elements need not remain in the original list.

valid = [temp for temp in temps if temp > -273.15 and temp < 1000]

Why it fails: Strict inequalities exclude readings exactly equal to -273.15 and 1000, but the requirement is inclusive. The comprehension structure is otherwise correct, which makes the option tempting; only the comparison operators at both boundaries are wrong, dropping valid edge values.

valid = [] for t in temps: if t > -273.15 and t < 1000: valid.append(t)

Why it fails: The bounds use strict inequalities, excluding readings exactly equal to -273.15 and 1000, whereas the requirement is inclusive (>= and <=). It tempts because the loop-and-append pattern is otherwise correct, but the boundary comparison operators silently drop valid edge values.

valid = list(filter(lambda t: t >= -273.15, temps))

Why it fails: The lambda tests only the lower bound, so readings above 1000 pass through unfiltered. It tempts because filter with a lambda is a genuine filtering idiom, but the predicate omits the upper-bound condition the requirement specifies, admitting invalid high temperatures.

if not flag: flag = True; action1() else: flag = False; action2()

Why it fails: The branch tests the old value before assignment, so action1 runs only when flag was already True, and the flag is set to the same value rather than flipped. No toggle occurs. This suits idempotent set-and-act logic where the flag is assigned a fixed target state.

if flag: flag = False; action1() else: flag = True; action2()

Why it fails: The branches run action1 when flag was already True and action2 when it was False, so the action reflects the pre-toggle state, not the new value. Toggling must occur before the branch. This structure suits state-dependent dispatch where the current value, not the flipped one, selects the action.

flag = not flag; if flag: action2() else: action1()

Why it fails: The flag is toggled first, but the branches are inverted: action2 runs when flag is True and action1 when False, contradicting the required mapping. Swapping the two calls would satisfy the scenario. This pattern is correct when the action mapping is intentionally reversed relative to the flag.

for num in numbers: if num > 0: total += num else: break

Why it fails: The break exits the loop at the first non-positive number, so any positive values appearing later in the list are never summed. It is tempting because break terminates iteration early, which is correct when searching for a single match or validating that all elements satisfy a condition.

for num in numbers: if num <= 0: pass else: total += num

Why it fails: The pass branch still iterates every element, so no efficiency is gained over a plain conditional add, and the inverted logic obscures intent. It is tempting because pass is a legitimate placeholder that skips the current iteration, and would suit a loop where some elements genuinely require no action.

for num in numbers: if num > 0: total += num else: continue

Why it fails: This is functionally correct but not the most efficient: continue adds a redundant branch, whereas a single positive guard with no else achieves the same sum. It is tempting because continue is the idiomatic way to skip unwanted elements when several distinct conditions must each be filtered out.

(10 > 5) and (5 < 3)

Why it fails: False: (10 > 5) is True but (5 < 3) is False, so True and False = False.

not (0 or 1)

Why it fails: False: not (0 or 1): 0 or 1 is 1 (True), so not True = False.

5

Why it fails: 5 is the middle element.

2

Why it fails: 2 is the second element after sorting.

9

Why it fails: 9 is the largest, at the end.

print([num for num in numbers if num % 2 == 0])

Why it fails: This prints the entire list of evens at once, not each number individually.

for num in numbers: print(num if num % 2 == 0 else None)

Why it fails: This prints None for odd numbers, not desired.

print([num % 2 == 0 for num in numbers])

Why it fails: This creates a list of booleans, not printing the numbers.

A list of even numbers squared

Why it fails: This is true but the specific list is [0,4,16,36,64]; however the answer C is more precise.

A generator object

Why it fails: Square brackets denote a list comprehension, which materialises the full list immediately; a generator would require parentheses or a yield. Confusing the two is tempting because both are lazy-looking iterables, but only generator expressions defer evaluation, and this syntax does not.

A list of squares of all numbers from 0 to 9

Why it fails: The if clause restricts iteration to even values, so odd squares such as 1, 9, 25, 49 and 81 never appear. Ignoring the filter is tempting because range(10) alone spans 0 to 9, but the condition removes every odd x before squaring occurs.

Move else inside the if block

Why it fails: This would not change the logic; else still prints for each non-matching item.

Replace break with continue

Why it fails: continue does not terminate loop; else clause will always execute.

Use a flag variable to track found status

Why it fails: This works but is not the most Pythonic; for-else is preferred.

for i in range(len(lst)):

Why it fails: Incorrect: `range(len(lst))` generates indices 0 to len(lst)-1, which iterate forward, not reverse.

for item in lst[-1::-1]:

Why it fails: Incorrect: Slicing `lst[-1::-1]` creates a new reversed list, which is not iterating over the original list in place.

for item in lst:

Why it fails: Incorrect: Iterating over `lst` directly visits elements in their original forward order.

1 2 3 Done

Why it fails: Neither 3 nor Done are printed.

1 2 Done

Why it fails: Else clause does not execute because break occurred.

1 2 3

Why it fails: break occurs before printing 3.