Dictionaries & Sets
You'll learn to
- -Create and use dictionaries: access, get with a default, and iterate keys/values/items
- -Use sets for fast membership testing and removing duplicates
- -Build early intuition for why dict/set lookups feel instant compared to scanning a list
Lists and tuples are great when order matters and you look things up by position. A lot of real problems instead need lookup by name - "what's this user's email," "have I seen this ID before." That's exactly what dictionaries and sets are built for.
Dictionaries: Key-Value Pairs
A dict maps keys to values - user["name"] doesn't mean "the item at position 0," it means "whatever value is stored under the key 'name'." Direct indexing (user["email"]) raises a KeyError if the key doesn't exist, which is why .get() is usually the safer choice when a key might be missing - it returns None (or a default you specify) instead of crashing. .items() is what you'll reach for constantly when you need both the key and the value while looping.
Sets: Unique, Unordered Collections
A set holds unique values with no guaranteed order - adding a duplicate is silently a no-op rather than an error. The two things sets are best at are exactly what the example shows: checking "have I seen this before" with in, and collapsing a list down to its unique values by wrapping it in set(...).
Why in Feels Instant for Dicts and Sets
Here's a teaser worth sitting with, even before you've formally learned Big-O notation (that's coming soon, and it's the very next thing this course covers): checking "is this value in my collection" with a list means Python may have to look at every single item, one at a time, until it finds a match or reaches the end. For a dict or a set, membership checks don't scan at all - Python computes where the value should be directly, so the check takes roughly the same tiny amount of time whether the collection has 10 items or 10 million.
That difference - scanning every item versus jumping straight to the answer - is the first real taste of algorithmic efficiency in this course. Phase 2 gives it a name (O(n) vs O(1)) and a rigorous way to reason about it. For now, the intuition is enough: prefer a set or dict over a list when all you need is "does this exist," especially over a large collection.
Does it matter whether you check membership in a list of a million items versus a set of a million items?
"Not really, in is in, it should be about the same either way."
"It matters a lot at that scale. A list membership check (x in my_list) may have to scan every element in the worst case, so it gets slower as the list grows. A set (or dict) computes a value's position directly, so a membership check stays roughly constant-time regardless of size. If a program is repeatedly checking membership against a large collection, switching that collection from a list to a set is often the single biggest performance win available."