Choose Python Lists, Dictionaries and Sets: Worked Task

A useful container choice starts with the question you need to answer. This exercise asks three different questions about fictional furniture requests: what arrived and in which order, how many units remain for each item, and which item names were initially available. One container does not have to answer all three. You will justify the choices before processing the queue.

Documentation boundary

The Python 3.12 data-structures tutorial describes lists, dictionaries and sets. Lists retain sequence positions; dictionaries associate keys with values; sets represent distinct members. The workshop deliberately uses these different properties rather than treating the three containers as interchangeable.

Write the requirements

Four requests arrive in this order: lamp, desk, lamp, chair. Initial stock is two lamps, one desk and no chairs. The acceptance rule is first come, first served: accept a request only when the remaining quantity is positive, then reduce that quantity by one. An availability snapshot records what was in stock before any request was processed; it is not a live stock report.

Before reading the answer, decide what would go wrong if requests became a set. Then decide what would be lost if stock became a list of item names with no quantity rule. Finally write the expected accepted sequence and rejected sequence. Each answer should refer to one requirement, not merely say that a container is faster or more convenient.

Process the queue

requests = ["lamp", "desk", "lamp", "chair"]
stock = {"lamp": 2, "desk": 1, "chair": 0}
available = {name for name, count in stock.items() if count > 0}
accepted = []
rejected = []
for item in requests:
    if stock[item] > 0:
        accepted.append(item)
        stock[item] -= 1
    else:
        rejected.append(item)
assert accepted == ["lamp", "desk", "lamp"]
assert rejected == ["chair"]
assert available == {"lamp", "desk"}
assert stock == {"lamp": 0, "desk": 0, "chair": 0}
print(accepted, rejected)

The accepted sequence is lamp, desk, lamp. The rejected sequence contains chair. All three final quantities are zero. The initial availability snapshot still contains lamp and desk because its purpose was to record the starting situation. That snapshot is not evidence that either item can satisfy another request after processing finishes. Keep its name explicit so a reader cannot confuse the two time points.

The second lamp is not a duplicate error. It is a separate request that consumes the second unit. Removing it would leave one lamp in stock and answer a different question. This is why deduplication should follow a stated business meaning rather than be applied whenever repeated text appears. In this fictional queue, repetition is part of the information to preserve.

Diagnose a plausible failed solution

Suppose a solution reports only two accepted requests because it first replaces requests with unique names. The error happened before the stock loop began: the transformation discarded an event. Restore the original queue and rerun the acceptance rule. A different mistake is to subtract once for every item name regardless of availability, producing a negative chair quantity. Point to the missing positive-stock check rather than patching the final number.

Do not rely on the displayed order of the availability set as an answer. For a tidy written report, sort its members for presentation and say that sorting is a reporting choice. Preserve the request order independently. A correct report can show an alphabetical membership summary alongside a chronological event list without pretending that they describe the same kind of ordering.

Extend the task without hiding uncertainty

Add a request for sofa. The original programme assumes every requested name exists in stock, so first choose an explicit policy for an unknown item. One sensible extension records sofa as an unknown request separately from an out-of-stock item. Write that category in the result table before changing the code. Combining unknown and unavailable might be acceptable for another task, but it loses a diagnostic distinction here.

Your finished artefact should include the four original requests, the initial quantities, both ordered outcome lists and the final stock table. Add a sentence explaining why the starting availability snapshot is intentionally unchanged. For self-assessment, swap the two lamp requests with the desk request and check which outputs change in order and which quantities remain the same. This separates an order-sensitive requirement from a quantity invariant.

Questions for this exercise

Official documentation

• Data structures

Explore the Courses overview or use Contact for general enquiries. This is an original INTIAU editorial self-study exercise; no qualification is awarded.

View the study diagram