Grade 8 AI & Computer Science Practice Questions — Set 11

ExplanationA generator function runs none of its code when it is first called — counter(5) only creates a paused generator object. Each next() call resumes execution from exactly the point after the previous yield, not from the top of the function. The first next(g) runs the loop up to i = 1 and yields 1 * 1, so first = 1. The second next(g) resumes right after that yield, advances the loop to i = 2, and yields 2 * 2, so second = 4. The key idea being tested is that sum(g) does not restart the generator from i = 1: it keeps pulling from the same paused state, running i = 3, 4, and 5 to yield 9, 16, and 25, which add up to 50, giving (1, 4, 50). The sequence (1, 4, 55) would only occur if sum() re-ran the whole generator from scratch instead of continuing where next() left off. The sequence (0, 1, 29) assumes the loop counts from i = 0, but range(1, n + 1) always starts at 1. The sequence (1, 2, 12) drops the squaring inside the yield statement and treats each yielded value as i instead of i * i.

ExplanationPython evaluates default argument values exactly once, when the function is defined — not once per call. Since cart=[] creates one list object at definition time, every call that omits the cart argument shares that SAME list. The first call appends 'apple' to it, the second appends 'banana' to that already-modified list, and the third appends 'cherry' — so by the third call the shared list already contains all three items. This is one of Python's most notorious gotchas; the fix is def add_item(item, cart=None): if cart is None: cart = [].

Explanationlist.copy() (like list[:] or list(x)) performs a SHALLOW copy: it creates a new outer list, but every element inside is copied by REFERENCE, not by value. For immutable elements like 1 and 2 this distinction is invisible, but list_a[2] and list_b[2] both point to the exact same inner list object [3, 4]. Appending 5 through list_b[2] mutates that shared object, so the change is visible through list_a too. To get full independence for nested structures, you need copy.deepcopy(list_a), which recursively copies every nested mutable object.

ExplanationInside an f-string's format spec (after the colon), ',' inserts a thousands separator and '.2f' formats as fixed-point with exactly 2 digits after the decimal, padding with a zero if needed. This happens because the comma groups '1' and '234' for the thousands separator, and .2f turns .5 into .50 by padding to exactly two decimal digits. These two specifiers combine freely — the general form is {value:,.Nf} for currency-style formatting, which is exactly why it's the standard way to print prices in Python.

ExplanationThe ^ operator on sets computes the SYMMETRIC difference: everything that appears in a or b but NOT in both. Working it out: a has {1,2,3,4}, b has {3,4,5,6}. The elements 3 and 4 appear in BOTH sets, so they are excluded. What remains is 1 and 2 (only in a) plus 5 and 6 (only in b), giving {1, 2, 5, 6}, because those are exactly the elements NOT shared by both sets. This differs from a | b (union, all 6 elements), a & b (intersection, just {3,4}), and a - b (elements only in a, just {1,2}).

ExplanationBinary search's defining property is that each comparison eliminates half of the remaining candidates, giving O(log n) worst-case comparisons. For n=10, the number of times you can halve 10 before reaching a single element (or empty range) is ceil(log2(10)) = ceil(3.32) = 4. Concretely: 10 candidates -> ~5 -> ~2-3 -> ~1 -> 0 (empty, search space exhausted), which is 4 comparisons in the worst case. This logarithmic scaling is exactly why binary search on a sorted list of a million items needs only about 20 comparisons, not a million.

ExplanationA sorting algorithm is called STABLE if it never swaps the relative order of two elements that are considered equal by the comparison key — here, two students sharing the same grade. Python's built-in sorted() and list.sort() are guaranteed stable (they use Timsort), which is exactly why 'sort by grade, keeping alphabetical order for ties' works correctly if the list was already alphabetical: you simply sort by grade once, and stability preserves the earlier alphabetical order within each grade group. An UNSTABLE sort (like a naive quicksort) offers no such guarantee — ties could end up in any order.

ExplanationThe 'raise NewException(...) from original_exception' syntax explicitly chains exceptions: it sets the new exception's __cause__ attribute to the original one. Python's traceback then prints BOTH: it shows the original ZeroDivisionError first, labeled 'The above exception was the direct cause of the following exception', followed by the new ValueError. This is deliberately different from a bare 'except: raise ValueError(...)' (which Python still chains automatically via __context__, but labels differently as 'During handling of the above exception, another exception occurred') — using 'from e' makes the causal relationship explicit and intentional rather than incidental.

Explanationlist() on any object calls iter(c) first, which invokes __iter__ — here that resets self.n to 0 and returns self (meaning Counter is its OWN iterator). Then list() repeatedly calls __next__: first call has n=0 which is <3, so n becomes 1 and 1 is returned; second call has n=1<3, so n becomes 2 and 2 is returned; third call has n=2<3, so n becomes 3 and 3 is returned; fourth call has n=3, which is NOT <3, so StopIteration is raised and list() stops collecting. The result is [1, 2, 3]. This is the exact protocol (__iter__ returning an object with __next__, which eventually raises StopIteration) that powers every for-loop in Python under the hood.

ExplanationSeparate chaining handles collisions by letting each bucket hold a small COLLECTION (commonly a linked list) of entries rather than just one. When 'dog' also hashes to bucket 3, it is appended to that bucket's chain alongside 'cat' rather than overwriting it or erroring. Looking up a key then means: compute its bucket, then walk that bucket's chain comparing each stored key until a match is found (or the chain ends, meaning the key is absent). This is why hash table performance degrades if TOO many keys collide into the same bucket — the chain gets long and lookup degrades from O(1) average toward O(n) worst case, which is exactly why a good hash function spreading keys evenly matters.

ExplanationTrace the operations step by step: q.append(1) makes the deque [1]. q.append(2) adds to the right, making it [1, 2]. q.appendleft(0) adds to the LEFT, making it [0, 1, 2]. q.popleft() removes and returns the leftmost element, which is 0, leaving the deque as [1, 2]. This left-add/right-add/left-remove combination is exactly why deque (double-ended queue) is the standard Python structure for implementing an efficient FIFO queue — unlike list.pop(0), which is O(n) because it has to shift every remaining element, deque's popleft() is O(1).

ExplanationEven though Python's integers can grow arbitrarily large (so the MATH of factorial(1500) is not the problem), each recursive call to factorial() creates a new stack frame that stays on the call stack until that call returns. factorial(1500) needs roughly 1500 nested, not-yet-returned calls before the base case n==0 is reached and the unwinding begins — but Python's interpreter enforces a default limit of 1000 stack frames (sys.getrecursionlimit()) specifically to prevent a runaway recursive call from crashing the underlying C stack. Exceeding it raises RecursionError: maximum recursion depth exceeded, well before the actual arithmetic ever becomes a problem. An iterative loop, or sys.setrecursionlimit() with caution, would sidestep this.

Explanationjson.dumps() converts a Python object into a JSON-formatted string, translating Python types to their JSON equivalents: dict keys and string values MUST use double quotes in valid JSON (Python's single quotes are not valid JSON syntax), and Python's None specifically maps to JSON's null keyword (JSON has no concept of 'None' — null is its only representation of an absent value). So the dict becomes {"name": "Aisha", "age": 16, "city": null}, with True/False similarly becoming JSON's lowercase true/false. This exact mapping is why JSON is a reliable interchange format between Python and virtually any other language.

Explanationdf['score'] > 70 evaluates elementwise, producing a boolean Series [True, False, True] (85>70, 62 is not >70, 91>70). Using that boolean Series to index df (df[boolean_series]) keeps only the rows where the mask is True — Riya's row and Meera's row, dropping Kabir's. Then ['name'] on that filtered DataFrame selects just the name column from the remaining rows, giving a Series with 'Riya' and 'Meera'. This filter-then-select chaining (df[condition][column]) is one of the most common patterns in real pandas data-analysis code.

Explanationcsv.DictReader's defining behavior is to automatically treat the FIRST row of the file as the fieldnames (unless you explicitly pass a different fieldnames argument), rather than yielding it as data. So for the file name,score / Aisha,85 / Rohan,72, DictReader reads 'name,score' once at initialization to learn the field names, then produces one dict per REMAINING row: {'name': 'Aisha', 'score': '85'}, then {'name': 'Rohan', 'score': '72'}. Note both values come back as strings ('85', not 85) — CSV has no type information, so converting 'score' to an int is something your code must do explicitly, e.g. int(row['score']).

ExplanationPython's 'and'/'or' operators do NOT return True/False the way many languages do — they return one of the actual OPERANDS, chosen by short-circuit logic. For 'and': if the first operand is falsy (0, '', None, False, empty containers), Python immediately returns that first operand WITHOUT evaluating the second one at all, since the overall result must be falsy regardless. Here 0 is falsy, so 0 and 'hello' returns 0 directly — 'hello' is never even looked at. This matters practically: it's why patterns like config.get('key') or 'default' work (returns the dict value if truthy, otherwise falls through to 'default'), and why an expression like x and x.attribute safely avoids an AttributeError when x is None.

Explanation== checks VALUE equality (do these two objects represent the same value?), while 'is' checks IDENTITY (are these literally the same object in memory, i.e., same id())? For 300 == 300, both sides have the value 300, so == is True regardless of implementation details. But CPython (the standard Python implementation) has a small-integer cache that pre-creates and reuses single shared objects for integers roughly -5 through 256, purely as a memory/speed optimization — numbers outside that range, like 300, are typically allocated as fresh, separate objects each time. So a is b is often False for 300 (implementation-dependent, not guaranteed by the language spec), even though a == b is always True. The practical lesson: always use == for value comparison; reserve 'is' specifically for identity checks like 'is None'.

ExplanationReading interest_rate on an instance (like acc1.interest_rate before any assignment) falls back to the shared class-level attribute if the instance has no attribute of its own name. But ASSIGNING to acc1.interest_rate = 0.05 does something different: it creates a brand-new instance attribute named interest_rate directly on acc1, which then shadows (takes priority over) the class attribute whenever accessed through acc1 specifically. The class attribute BankAccount.interest_rate itself is completely unchanged, and acc2 — having no instance attribute of its own — still falls back to reading the original class-level 0.02. To actually change the shared value for every instance, you would need to assign to BankAccount.interest_rate = 0.05 (on the class itself), not on one instance.

ExplanationPython's multiple-assignment unpacking takes any sequence (list, tuple, etc.) on the right and assigns its elements POSITIONALLY, left to right, to the names on the left: top gets scores[0]=91, mid gets scores[1]=85, low gets scores[2]=78. This requires an EXACT count match — if scores had 4 elements, Python would raise ValueError: too many values to unpack (expected 3), since it has no rule for silently dropping or combining extra values (unless you explicitly use a starred name like *rest to absorb the leftovers, e.g. top, mid, *rest = scores).

Explanationword[-3:] means 'start 3 characters from the end, go through the end': for 'Bengaluru' (9 characters, indices 0-8: B-e-n-g-a-l-u-r-u), index -3 lands on 'u' at position 6, so the slice covers positions 6,7,8 giving 'uru'. word[::2] means 'start at the implicit beginning, go to the implicit end, step by 2' — collecting every second character: index 0='B', 2='n', 4='a', 6='u', 8='u', which concatenates to 'Bnauu' (5 characters, since a 9-character string has 5 even indices: 0,2,4,6,8). Verified directly in Python: 'Bengaluru'[-3:] == 'uru' and 'Bengaluru'[::2] == 'Bnauu'.

ExplanationThe 'in' operator's cost depends entirely on the underlying data structure. For a list, Python has no choice but to scan from the start until it finds a match or reaches the end — O(n) in the worst case, meaning the check gets slower as the list grows. A set is backed by a hash table (the same mechanism as a dict's keys): it computes the item's hash and jumps almost directly to where it would be, giving O(1) average-case lookup regardless of how large the set is. Measured directly: checking membership 200,000 times against a 200,000-element collection took roughly 1.5ms total for a set versus about 1.5 SECONDS for a list in the same test — a difference of roughly 1000x, which only grows as the collection gets bigger. This is precisely why 'convert the list to a set first' is one of the most common real performance fixes in Python code, because repeated membership checks are exactly the pattern where the O(n)-vs-O(1) gap matters most.