Lists, dicts, sets, tuples

Two questions decide everything: mutable? hashable?

Python gives you four built-in containers, and choosing between them is not taste — it is two yes/no questions. Is it mutable? — can you change it in place after creation. Is it hashable? — can Python compute a stable hash so the object can be a dict key or a set member. These two properties are linked: an object is hashable only if its value can’t change underneath the hash, so mutable built-ins are not hashable. That single rule explains why a list cannot be a dict key but a tuple can.

• list — ordered, mutable, the workhorse sequence. Closest to a JS Array, but the methods differ (.append(), not .push(); .sort() mutates in place and returns None). Append is amortized O(1); insert(0, x), del lst[0], and x in lst are all O(n). Not hashable.
• dict — a hash map with guaranteed insertion order since Python 3.7. Keys must be hashable; lookup, insert, and delete are O(1) average. It is JS’s Object and Map unified into one type: string-keyed and arbitrary-hashable-keyed, ordered, fast.
• set — an unordered collection of unique, hashable members. O(1) membership, plus first-class | union, & intersection, - difference. Like JS Set, but with real set algebra built in.
• tuple — ordered, immutable, and hashable if every element is hashable. JavaScript has no equivalent. It is the type for fixed records, multiple return values, and — crucially — composite dict/set keys.

Together these four types cover every data-shaping task, but they are not interchangeable. When you pick the wrong one — a list for membership or a tuple where a dict belongs — the cost shows up as real algorithmic complexity, not a style warning.

point = (3, 4)              # tuple: fixed record, hashable
grid = {point: "origin"}   # tuple as a dict key — works
grid[[3, 4]]               # TypeError: unhashable type: 'list'

x, y = point               # unpacking a tuple into two names
def bounds(): return 0, 100  # returning a tuple (the comma makes it)
lo, hi = bounds()

The cheat sheet, and the JS translation

When you come from JavaScript, the mistake isn’t syntax — it’s mapping Array onto everything. JS makes you fake a set with an object ({}) or a Map, fake set algebra with filters, and has no immutable record at all. Python splits those jobs across four purpose-built types, and the cost of using the wrong one is real algorithmic complexity, not just style.

The asterisk on tuple matters: a tuple is hashable only if all its elements are. (1, 2) is a fine key; (1, [2]) is not, because it nests a list. Hashability is recursive.

Identity vs equality, and the mutable-default trap

Two pitfalls bite engineers crossing from JS. First, identity (is) vs equality (==). == compares values; is compares object identity (same object in memory) and is what None/True/False checks should use. They diverge in ways that look like magic: [1,2] == [1,2] is True but [1,2] is [1,2] is False (two distinct lists). CPython caches small integers and short strings, so 256 is 256 may be True while 257 is 257 is False — an implementation detail you must never rely on. Rule: use == for value checks, reserve is for None and other singletons.

Second, the mutable default argument. A default value is evaluated once, at function definition, and shared across every call — so a mutable default like [] or {} accumulates state between calls, a bug that looks like haunting.

def add(item, bucket=[]):     # bucket is created ONCE, shared forever
    bucket.append(item)
    return bucket

add("a")        # ['a']
add("b")        # ['a', 'b']  ← surprise: the same list persisted

def add(item, bucket=None):   # the fix: sentinel + fresh object per call
    if bucket is None:
        bucket = []
    bucket.append(item)
    return bucket