Hard Difficulty Questions

max_retries

Why it fails: PEP 8 reserves lowercase with underscores for variables and functions; constants use all uppercase letters, so MAX_RETRIES is required. The lowercase form is tempting because it is valid Python and matches ordinary variable naming, which is exactly when it would be the right style.

1st_retry_limit

Why it fails: Cannot start with a digit.

maxRetries

Why it fails: CamelCase is for classes, not constants.

{'key': 'old_value'}

Why it fails: This value would remain only if the exhibit's code never modified the dictionary, for example if an update targeted a copy or a new key was added instead. Choosing it assumes no effective mutation occurred. The correct option reflects what the executed statements actually assign or update.

{'another': 'dict'}

Why it fails: The exhibit's code determines the actual output; this value would only appear if the dictionary were reassigned or a new key inserted. Choosing it suggests assuming mutation occurred when the operations returned a different object or left the original unchanged. The correct option reflects the precise sequence of assignments and method calls shown.

None

Why it fails: None would result only if the code raised an unhandled exception or a function returned nothing implicitly. Selecting it indicates misreading the exhibit as erroring or lacking a return statement. The correct option follows the actual control flow and printed value produced by the statements shown.

<class 'str'>

Why it fails: Dividing an int by a float produces a float, so type(z) is <class 'float'>, not str. String is tempting because print() displays text, but print converts the value for output; it does not change the object's type.

<class 'complex'>

Why it fails: Dividing an int by a float always yields a float in Python, so z is 3.333... and type(z) prints <class 'float'>. Complex results only arise when an operand is complex, such as 1j, or via complex() or cmath functions; no imaginary component exists here.

<class 'int'>

Why it fails: True division with a float operand always yields a float, so z is 3.333... and type() returns <class 'float'>. Integer is tempting because 10 looks whole, but Python 3's / operator never truncates, unlike floor division //.

[4, 5]

Why it fails: Negative slicing stops before the end index, so -1 excludes the final element; [4, 5] would require the slice [-2:]. It tempts because -1 is often mistaken for the last inclusive position, but Python slice end bounds are always exclusive.

[2, 3]

Why it fails: Starting at -3 selects index 2, not index 1, so the slice begins at 3; [2, 3] would require [-4:-2]. It tempts because counting backwards from the list's end is easily off by one, but negative indices map directly onto positions from the right.

[3, 4, 5]

Why it fails: The end index -1 is exclusive, so element 5 is never included; [3, 4, 5] would need an omitted stop or [:]. It tempts because -1 intuitively reads as the last element, yet slicing always stops one position before the specified end.

10 // 2 == 5.1

Why it fails: Floor division 10 // 2 yields the integer 5, and 5 does not equal the float 5.1, so the comparison is False. Floor division is correct where an integer quotient is required, such as indexing or grouping counts.

10 % 2 == 1

Why it fails: The modulo operator returns the remainder, so 10 % 2 yields 0, not 1, making the comparison False. It tempts because modulo is the standard tool for testing divisibility, and it would be correct if the stem asked for an odd number, where n % 2 == 1 holds.

Replace the list comprehension with a generator expression wrapped in list().

Why it fails: This still forces immediate evaluation into a list.

Use a for loop with the .append() method instead of comprehension.

Why it fails: Same memory consumption as comprehension.

Increase the system's available memory via configuration.

Why it fails: Not a programming solution; does not address the root cause.

The dictionary does not have an 'action' key

Why it fails: The code calls the dictionary as a function, `rule('action')`, raising a `TypeError` before any comparison, so nothing prints. Dictionary values are retrieved with square brackets, `rule['action']`. The option is tempting because a missing key would also yield no output, but that scenario requires `KeyError` handling, not callable syntax.

The developer used rule['action'] instead of rule.get('action')

Why it fails: Subscripting with rule['action'] is valid and would work; the snippet's actual bug is calling rule('action'), treating the dict as callable, which raises TypeError. The .get() method only matters when a key may be absent, since it returns None instead of raising KeyError.

The for loop syntax is incorrect; it should be for rule in rules:

Why it fails: The loop syntax `for rule in rules:` is valid Python and correctly iterates the list; the failure lies in `rule('action')`, which attempts to call the dictionary as a function rather than subscript it. Iteration syntax would be the culprit only if the loop raised a `SyntaxError` before execution, which it does not here.

Use string splitting to extract the numeric part, then convert to float and round to the nearest integer.

Why it fails: Rounding may not match the desired behavior (e.g., 45.2 rounds to 45, but 45.8 rounds to 46). The original intent is to truncate? The problem says 'integer result', but rounding is not exactly truncation.

Use a regular expression to extract the number and convert to float, then convert to int.

Why it fails: Regular expressions are outside the PCEP exam scope and may be overkill for this task.

Use the .replace() method to remove the '%' character and then convert to int.

Why it fails: This works only for integer percentages; for '45.2%', removing '%' gives '45.2' which cannot be converted to int.

Both in order

Why it fails: Python matches the first except clause whose exception type matches, then exits the handler chain; the bare except is never reached once ValueError is caught. It is tempting because both clauses could logically apply. It would be correct only if the ValueError clause re-raised the exception, allowing the bare except to catch it.

Neither; program crashes

Why it fails: A matching except ValueError clause catches the exception, so the program continues normally rather than crashing. It is tempting because an unhandled exception does terminate the program. It would be correct if no except clause matched the raised exception type, or if the exception were raised outside any try block.

The bare except clause

Why it fails: Python evaluates except clauses in order and stops at the first match; except ValueError matches before the bare except is considered. It is tempting because a bare except catches everything. It would be correct only if the specific ValueError clause were absent or listed after the bare except.

Lists have a fixed size once created.

Why it fails: Lists are dynamic; size can change.

Lists can only contain elements of the same data type.

Why it fails: Lists can contain mixed data types.

12

Why it fails: Exponentiation is right-associative, so 2 ** 3 ** 2 evaluates as 2 ** (3 ** 2), giving 2 ** 9 = 512. The value 12 would require (2 ** 3) * 2 or similar, mixing multiplication with exponentiation. The option tempts by treating the operators as left-associative.

64

Why it fails: Exponentiation is right-associative, so 2 ** 3 ** 2 evaluates as 2 ** (3 ** 2) = 2 ** 9 = 512, not 64. The value 64 equals (2 ** 3) ** 2, which assumes left-to-right grouping. The option tempts by applying the associativity of multiplication and addition.

256

Why it fails: Python's exponentiation operator ** is right-associative, so 2 ** 3 ** 2 evaluates as 2 ** (3 ** 2) = 2 ** 9 = 512, not 256. The value 256 arises from wrongly applying left-to-right associativity, giving (2 ** 3) ** 2 = 8 ** 2. Left-associativity applies to operators like subtraction, not exponentiation.

27

Why it fails: The exhibit does not evaluate to 27; this number typically arises from applying the wrong operator order or including an extra loop pass. 27 would be correct if the code multiplied the operands as shown in the alternative branch.

5

Why it fails: The exhibit's operations produce a value other than 5; this figure likely comes from treating a concatenation or floor division as the final result. 5 would be correct if the code returned the count of iterations rather than the accumulated value.

21

Why it fails: The exhibit's loop or arithmetic yields a different total than 21, so this value reflects a misread of the operator precedence or iteration count. 21 would be correct only if the code performed the alternative calculation shown, such as summing a different range.

TypeError

Why it fails: Incorrect. The call provides enough arguments for required parameters.

30

Why it fails: Incorrect. This would be the sum if c=10 and d=20 but a+b=0, which is not the case.

10

Why it fails: Incorrect. This is not the sum.

a = 1; b = 2

Why it fails: Valid syntax: multiple statements separated by semicolons are allowed on one line.

print('hello')

Why it fails: Valid syntax: `print('hello')` is a correct function call in Python 3.

for i in range(5): print(i)

Why it fails: Valid syntax: the `for` loop has a colon and proper indentation.

if x > 5: print('big')

Why it fails: Valid syntax: the `if` statement has a colon and proper indentation.

squares = []; for i in range(10): squares.append(i*i)

Why it fails: Correct but not the most efficient.

squares = list(map(lambda x: x*x, range(10)))

Why it fails: Works but less Pythonic.

squares = (i*i for i in range(10))

Why it fails: This is a generator, not a list.

TypeError

Why it fails: TypeError is raised when an operation is applied to an object of an inappropriate type, such as adding a string to an integer. It is tempting because a missing key can seem like a type mismatch, but dictionary subscript access raises KeyError, not TypeError.

ValueError

Why it fails: ValueError is raised when a function receives an argument of the right type but an inappropriate value, such as int('abc'). It is tempting because a missing key feels like a bad value, but dictionary subscript access raises KeyError, not ValueError.

AttributeError

Why it fails: AttributeError is raised when an attribute reference or assignment fails on an object, such as calling a non-existent method. It is tempting because dictionary keys are accessed with dot-like syntax in some languages, but Python dictionary lookups raise KeyError, not AttributeError.

Use input with a regex check to ensure only integers are entered.

Why it fails: Rejecting non-integer input leaves valid float entries such as 36.5 unprocessed, failing the graceful-handling requirement. Regex validation suits forms where only whole numbers are legitimate, but this scenario expects floats to be accepted and then truncated to int for processing.

Use a try-except block to catch ValueError and ask the user to re-enter.

Why it fails: A try-except block that catches ValueError and prompts re-entry does not solve the requirement to convert a float input to an integer by truncation; it merely rejects the float and forces the user to type an integer, which is a different workflow. This approach is tempting because try-except is the standard pattern for handling malformed input in Python, and it would be correct if the goal were to reject non-integer values entirely rather than to accept and truncate floats.

Use float(input()) and do not convert to int, store as float.

Why it fails: Storing the value as a float leaves the processing logic receiving a non-integer, contradicting the requirement to truncate to int. Float parsing is genuinely useful when decimal precision must be preserved, but here the downstream code expects an integer, so truncation after parsing is required.

mypackage.py

Why it fails: That would be a module, not a package.

module.py in the current directory

Why it fails: The import uses the package hierarchy, not the current directory.

Only mypackage/module.py is needed

Why it fails: Without __init__.py, Python does not recognize mypackage as a package (unless using namespace packages).