Every time I start a new Python project, one of the first decisions I make — often without even thinking about it consciously anymore — is which collection type to reach for. Do I need an ordered, changeable sequence? A fixed record that shouldn’t change? A group of unique values? A mapping of keys to values? Python gives me four core built-in collection types to answer these questions: lists, tuples, sets, and dictionaries. In this guide, I’ll walk through each one in depth, including how they work internally, when to use which, and the mistakes I’ve made learning the hard way.
Lists — Ordered and Mutable
A list is an ordered, mutable (changeable) collection that can hold items of any type, including mixed types.
fruits = ["apple", "banana", "cherry"]
fruits.append("date")
fruits[1] = "blueberry"
print(fruits) # Output: ['apple', 'blueberry', 'cherry', 'date']
print(fruits[0]) # Output: apple
print(fruits[-1]) # Output: date
print(len(fruits)) # Output: 4
print(fruits[1:3]) # Output: ['blueberry', 'cherry']
Internally, a Python list is implemented as a dynamic array of pointers to objects. This means:
- Indexing (
fruits[i]) is O(1) — constant time — because it’s direct memory offset access. - Appending to the end (
.append()) is amortized O(1), because CPython over-allocates extra capacity so it doesn’t need to resize on every single append. - Inserting or deleting at the beginning or middle (
.insert(0, x)or.pop(0)) is O(n), because every following element has to shift in memory.
I use lists constantly for anything ordered that will change over time — a queue of tasks, a running log of results, rows of data before processing.
Tuples — Ordered and Immutable
A tuple looks almost identical to a list but cannot be modified after creation.
coordinates = (10.5, 20.3)
person = ("Ali", 28, "Engineer")
print(coordinates[0]) # Output: 10.5
print(person[1]) # Output: 28
# This raises an error:
# coordinates[0] = 99 -> TypeError: 'tuple' object does not support item assignment
Because tuples are immutable, Python can apply certain optimizations: they take up slightly less memory than an equivalent list, and — importantly — tuples are hashable (as long as their contents are hashable), which means they can be used as dictionary keys or set elements, unlike lists.
locations = {
(40.7128, -74.0060): "New York",
(51.5074, -0.1278): "London"
}
print(locations[(40.7128, -74.0060)]) # Output: New York
I reach for tuples when I want to guarantee that a piece of data — like coordinates, an RGB color, or a database record — stays exactly as it was created, and I want the extra safety of it being immutable and hashable.
Sets — Unordered and Unique
A set is an unordered collection of unique, hashable elements.
colors = {"red", "green", "blue", "red"}
print(colors) # Output: {'red', 'green', 'blue'} (duplicates removed)
colors.add("yellow")
colors.discard("red")
print(colors)
a = {1, 2, 3, 4}
b = {3, 4, 5, 6}
print(a & b) # Intersection -> Output: {3, 4}
print(a | b) # Union -> Output: {1, 2, 3, 4, 5, 6}
print(a - b) # Difference -> Output: {1, 2}
print(a ^ b) # Symmetric difference -> Output: {1, 2, 5, 6}
Internally, sets are implemented using a hash table, the same underlying structure as dictionaries. This gives sets an average-case O(1) time complexity for membership testing (in), adding, and removing elements — dramatically faster than checking membership in a list, which is O(n).
big_list = list(range(1_000_000))
big_set = set(big_list)
print(999999 in big_list) # Slow: has to scan up to a million items
print(999999 in big_set) # Fast: hash lookup, essentially instant
I use sets whenever I need to deduplicate data or perform fast membership checks — like checking whether a username already exists in a large collection.
Dictionaries — Key-Value Mappings
A dictionary stores data as key-value pairs, where each key must be unique and hashable.
person = {
"name": "Ali",
"age": 28,
"job": "Engineer"
}
print(person["name"]) # Output: Ali
person["age"] = 29
person["city"] = "Lahore"
print(person)
for key, value in person.items():
print(f"{key}: {value}")
Output of the loop:
name: Ali
age: 29
job: Engineer
city: Lahore
Like sets, dictionaries are implemented as hash tables internally, giving average O(1) time complexity for lookups, insertions, and deletions by key. Since Python 3.7, dictionaries also guarantee insertion order — an implementation detail from 3.6 that became an official language guarantee in 3.7, so iterating over a dict now reliably returns items in the order they were added.
scores = {}
scores["math"] = 90
scores["science"] = 85
scores["art"] = 95
print(list(scores.keys())) # Output: ['math', 'science', 'art'] (guaranteed order)
Choosing the Right Collection Type
Here’s the mental checklist I actually use:
| Need | Use |
|---|---|
| Ordered, changeable sequence | List |
| Ordered, fixed/unchangeable sequence | Tuple |
| Unique items, fast membership checks | Set |
| Key-to-value mapping, fast lookups by key | Dictionary |
Converting Between Collection Types
I convert between these types often, especially to deduplicate or restructure data:
names = ["Ali", "Sara", "Ali", "John", "Sara"]
unique_names = set(names)
print(unique_names) # Output: {'Ali', 'Sara', 'John'} (order not guaranteed)
back_to_list = list(unique_names)
print(back_to_list)
name_tuple = tuple(names)
print(name_tuple)
name_counts = {name: names.count(name) for name in unique_names}
print(name_counts) # Output: {'Ali': 2, 'Sara': 2, 'John': 1}
Comprehensions for Every Collection Type
Once I understood list comprehensions, I realized Python offers the same concise syntax for building tuples (technically generator expressions wrapped in tuple()), sets, and dictionaries too:
numbers = [1, 2, 3, 4, 5]
# List comprehension
squares = [n**2 for n in numbers]
print(squares) # Output: [1, 4, 9, 16, 25]
# Set comprehension -- automatically deduplicates
remainders = {n % 3 for n in numbers}
print(remainders) # Output: {0, 1, 2}
# Dictionary comprehension
square_map = {n: n**2 for n in numbers}
print(square_map) # Output: {1: 1, 2: 4, 3: 9, 4: 16, 5: 25}
# Tuple -- built from a generator expression
square_tuple = tuple(n**2 for n in numbers)
print(square_tuple) # Output: (1, 4, 9, 16, 25)
I reach for comprehensions constantly because they’re usually faster than the equivalent explicit loop (fewer Python-level function calls and attribute lookups per iteration) and, once I got comfortable with the syntax, more readable too.
Nested Collections
Real-world data is rarely flat — I frequently work with lists of dictionaries, dictionaries of lists, or other nested combinations:
students = [
{"name": "Ali", "grades": [85, 90, 78]},
{"name": "Sara", "grades": [92, 88, 95]},
]
for student in students:
average = sum(student["grades"]) / len(student["grades"])
print(f"{student['name']}: {average:.1f}")
Output:
Ali: 84.3
Sara: 91.7
This pattern — a list of dictionaries, each holding its own nested list — is exactly how most JSON API responses are structured once parsed into Python, which is why comfort with nested collections translates directly into comfort working with real-world APIs.
Copying Collections Correctly
Something that caught me off guard early on: copying a collection doesn’t always copy what’s inside it. A shallow copy duplicates the outer collection but still shares references to any nested mutable objects inside:
import copy
original = [[1, 2], [3, 4]]
shallow = original.copy()
shallow[0].append(99)
print(original) # Output: [[1, 2, 99], [3, 4]] -- inner list was shared!
deep = copy.deepcopy(original)
deep[1].append(100)
print(original) # Output: [[1, 2, 99], [3, 4]] -- unaffected this time
For nested structures, I now default to copy.deepcopy() whenever I genuinely need full independence, since a plain .copy() or slice ([:]) only protects the outermost layer.
Memory and Performance Notes
- Lists use more memory per element than tuples of the same content, because lists need extra space reserved for future growth (over-allocation strategy).
- Sets and dictionaries use noticeably more memory per element than lists or tuples, because the hash table needs extra space to keep collisions low and lookups fast — this is a classic time-vs-memory tradeoff.
- Choosing a list where a set would be more appropriate is one of the most common performance mistakes I’ve seen (and made) — a membership check (
x in my_list) inside a loop over a large list can silently turn an otherwise fast script into something that takes minutes instead of milliseconds.
Common Mistakes I’ve Made
- Using a list for membership-heavy logic, not realizing it’s O(n) per check instead of O(1) with a set.
- Trying to use a list as a dictionary key, forgetting that only hashable (immutable) types like tuples, strings, and numbers are allowed as keys.
- Assuming set order is predictable — sets are unordered, and while CPython’s implementation may show consistent behavior in casual testing, it’s not something to rely on.
- Mutating a list while iterating over it, which causes elements to be skipped unexpectedly — I now iterate over a copy (
for item in my_list[:]:) when I need to modify the original during the loop.
Real-World Applications
I use lists for processing rows from a CSV file, tuples for returning multiple fixed values from a function (like return (mean, median, mode)), sets for deduplicating scraped URLs or validating unique email submissions, and dictionaries for essentially every configuration object, API response, and cache I build. Understanding which structure fits which situation is one of the most immediately useful skills in professional Python development — it shows up in code review feedback constantly.
Frequently Asked Questions
Can a list contain different data types? Yes — Python lists are heterogeneous by design; a single list can hold integers, strings, other lists, or any object mixed together.
Why can’t I use a list as a dictionary key? Because dictionary keys must be hashable, and lists are mutable, which makes them unhashable by design — their hash value would change if the contents changed, breaking the hash table.
Are dictionaries ordered in Python? Yes, as of Python 3.7+, dictionaries officially preserve insertion order as a language guarantee.
What’s faster: checking membership in a list or a set? A set, almost always — set membership checks are average O(1) versus a list’s O(n).
Summary
Lists, tuples, sets, and dictionaries are the four pillars of everyday Python data handling. Lists give me ordered flexibility, tuples give me safe immutability, sets give me speed and uniqueness, and dictionaries give me fast key-based lookups. Picking the right one isn’t just a style choice — it directly affects the performance, correctness, and readability of the code I write.
