Sorting, Searching, and Filtering Patterns in Python

The Foundation: sorted() and the Art of Keys

Here's the thing about sorting: most developers think they understand it. Then they hit a problem where they need to sort objects by attribute, or sort strings case-insensitively, or juggle five different sorting criteria simultaneously. That's when the real game begins.

Python's sorted() function is your Swiss Army knife here. Unlike the .sort() method (which mutates the original list), sorted() returns a new sorted sequence. The magic ingredient? The key parameter.

Before looking at the key parameter, let's see what happens without it. Python's default sort compares elements directly using their natural ordering, numbers by value, strings by Unicode code points. That last part trips people up more than you'd expect.

# Without key: sorts lexicographically (alphabetically)
names = ["alice", "Bob", "charlie"]
sorted(names)  # ['Bob', 'alice', 'charlie'] - uppercase comes first

You see that? Capital letters sort before lowercase. That's because Python compares by ASCII value, and uppercase letters have lower values. If you want case-insensitive sorting, you need a key. This is one of those gotchas that's easy to miss in development (where your test data is tidy) and painful to discover in production (where real user input is messy).

The key parameter accepts any callable, a function, a lambda, a method reference, and Python will call it on each element to produce a comparison value. The sort happens on those derived values, but the original elements are what end up in the output.

# With key: transform each element before comparison
names = ["alice", "Bob", "charlie"]
sorted(names, key=str.lower)  # ['alice', 'Bob', 'charlie']

The key function is applied to each element to extract a comparison value. Python compares those values, not the originals. So str.lower converts each name to lowercase for sorting purposes, but the original capitalization stays in the result.

This is crucial: the key function doesn't modify the data, it's purely for comparison logic.

Lambda vs. Built-in Extractors

For simple transformations, lambdas work fine. They're concise, inline, and don't require an import. But they do come with a cost, every lambda call involves Python's function dispatch overhead, and for large datasets that overhead accumulates.

numbers = [3, 1, 4, 1, 5, 9, 2, 6]
sorted(numbers, key=lambda x: -x)  # Descending: [9, 6, 5, 4, 3, 2, 1, 1]

But when you're sorting objects by attributes, built-in extractors are faster and more readable. The operator module gives you attrgetter and itemgetter, purpose-built tools that compile down to efficient bytecode.

from operator import attrgetter, itemgetter
 
class User:
    def __init__(self, name, age):
        self.name = name
        self.age = age
 
users = [
    User("alice", 30),
    User("bob", 25),
    User("charlie", 35),
]
 
# Slow (lambdas are callable overhead)
sorted(users, key=lambda u: u.age)
 
# Fast (direct attribute extraction)
sorted(users, key=attrgetter("age"))
 
# Even more readable when chaining
sorted(users, key=attrgetter("age", "name"))  # By age, then by name

The difference? attrgetter compiles to bytecode that's executed faster than lambda interpretation. For large datasets, this matters. Benchmarks typically show attrgetter running 15–25% faster than an equivalent lambda on datasets of tens of thousands of elements. At a million elements, that gap becomes very meaningful.

For dictionaries, use itemgetter. It does the same thing as attrgetter but for dictionary keys, and it's equally efficient:

people = [
    {"name": "alice", "score": 95},
    {"name": "bob", "score": 87},
    {"name": "charlie", "score": 92},
]
 
sorted(people, key=itemgetter("score"), reverse=True)
# [{'name': 'alice', 'score': 95}, {'name': 'charlie', 'score': 92}, {'name': 'bob', 'score': 87}]

Multi-Key Sorting: The Stability Hack

What happens when you need to sort by multiple criteria? "Sort by age, and within the same age, sort by name alphabetically."

Most developers think you need nested sorting logic. You don't. Python's sort is stable, which means equal elements maintain their original relative order. This property, combined with the ability to run multiple sorted passes, gives you a powerful multi-key technique.

users = [
    User("charlie", 30),
    User("alice", 30),
    User("bob", 25),
]
 
# Sort by age first
sorted_by_age = sorted(users, key=attrgetter("age"))
 
# Then by name (stable sort preserves age grouping)
sorted_by_name_then_age = sorted(sorted_by_age, key=attrgetter("name"))

But that's two passes. Here's the elegant way, sort in reverse order of priority. Because the sort is stable, the later pass preserves the relative order established by the earlier pass for elements that compare equal:

users = [
    User("charlie", 30),
    User("alice", 30),
    User("bob", 25),
]
 
# Sort by name, THEN by age (do secondary sort first)
sorted_users = sorted(users, key=attrgetter("name"))
sorted_users = sorted(sorted_users, key=attrgetter("age"))

Wait, that still feels clunky. Python 3.10+ gives you a cleaner approach with tuple unpacking. Tuple comparison is the real MVP here, it lets you express multi-key sorting in a single, readable pass.

# Tuple comparison: Python compares element-by-element
sorted(users, key=lambda u: (u.age, u.name))
# Sorts by age first, then name for ties

Why tuples work: Python compares tuples element-by-element. First it compares the first elements (u.age). Only if they're equal does it move to the second element (u.name). This is exactly what multi-key sorting needs. You're essentially telling Python "use this as the primary sort key, and this as the tiebreaker", all in one expression.

Want descending on age but ascending on name? You have two options: negate the numeric field, or use reverse=True when all fields should go the same direction.

sorted(users, key=lambda u: (u.age, u.name), reverse=True)  # Both descending
 
# Or mix them:
sorted(users, key=lambda u: (-u.age, u.name))  # Age descending, name ascending

Negating numeric values flips their sort order. It's a sneaky trick, but it works because -30 comes before -25 (ascending).

Reverse and Case-Insensitive: Small Parameters, Big Impact

The reverse=True parameter is straightforward, it just inverts the sort without adding any overhead to your key function. Use it whenever all your sort criteria point the same direction.

sorted([3, 1, 4, 1, 5], reverse=True)  # [5, 4, 3, 1, 1]

For case-insensitive sorting, we already covered it with key=str.lower. But here's a gotcha: what if you have mixed case data and want to preserve case while sorting case-insensitively?

words = ["Apple", "banana", "Cherry"]
sorted(words, key=str.lower)  # ['Apple', 'banana', 'Cherry'] - Correct!

Python applies the key function only for comparison, not for the output. The output is always the original element. This is a crucial design decision, the key is ephemeral, used only to determine order, then discarded. Your data comes out clean.

Timsort: Python's Secret Weapon

Here's something most Python tutorials skip entirely: the sorting algorithm Python actually uses is extraordinary. Python's sort is called Timsort, and it was designed specifically for real-world data, the messy, partially-ordered kind you actually encounter in production.

Timsort was created by Tim Peters in 2002 for CPython and has since been adopted by Java (for array sorting) and Android's sorting infrastructure, which tells you something about how good it is. The core insight behind Timsort is that real-world data is rarely random. It often contains runs, sequences of consecutive elements that are already sorted (or sorted in reverse). Timsort detects and exploits these runs instead of ignoring them.

The algorithm works by scanning the input for natural runs, reversing any descending runs to make them ascending, and then merging runs together using a merge sort strategy. For data that's already partially sorted, think a list of records where you're re-sorting after a small update, Timsort approaches O(n) performance instead of the O(n log n) you'd expect. For random data, it performs the same as merge sort: O(n log n) worst case, O(n log n) average case, O(n) best case.

What makes Timsort particularly useful for Python developers is that it's stable, equal elements always maintain their original relative order. We rely on this stability for the multi-key sorting tricks described earlier, and it also means you can safely sort objects that aren't fully comparable without accidentally scrambling your data. Timsort also uses O(n) memory in the worst case, which is a real consideration when you're sorting large datasets. Understanding that Python's sort is this sophisticated should give you confidence: when you call sorted(), you're not calling a naive algorithm. You're using one of the best practical sorting implementations ever designed, optimized for the data patterns that actually appear in software.

Custom Sort Keys

Beyond attrgetter and itemgetter, there are situations where your sort key needs to be genuinely custom, derived from business logic that can't be expressed as a simple attribute or dictionary lookup. Python's key mechanism handles this gracefully because the key can be any callable.

Consider a scenario where you need to sort status strings in a specific business-defined order rather than alphabetically. "URGENT" should come before "HIGH", which should come before "NORMAL", which should come before "LOW", that's not alphabetical, it's a domain-specific ordering.

# Custom priority ordering for status values
PRIORITY_ORDER = {"URGENT": 0, "HIGH": 1, "NORMAL": 2, "LOW": 3}
 
tasks = [
    {"name": "Fix login bug", "status": "HIGH"},
    {"name": "Update docs", "status": "LOW"},
    {"name": "Server outage", "status": "URGENT"},
    {"name": "Add feature", "status": "NORMAL"},
]
 
sorted(tasks, key=lambda t: PRIORITY_ORDER.get(t["status"], 99))
# Server outage (URGENT), Fix login bug (HIGH), Add feature (NORMAL), Update docs (LOW)

The .get() with a default of 99 is a defensive pattern, unknown statuses sort to the end instead of raising a KeyError. Another common pattern is sorting by computed values, like the length of a string or the result of a mathematical operation.

# Sort words by length, then alphabetically for same-length words
words = ["banana", "fig", "apple", "kiwi", "date"]
sorted(words, key=lambda w: (len(w), w))
# ['fig', 'date', 'kiwi', 'apple', 'banana']

You can also use class methods as keys, which is a clean pattern for domain objects. If your User class has a method that computes a sortable score, you can pass that method directly.

class Product:
    def __init__(self, name, price, rating, reviews):
        self.name = name
        self.price = price
        self.rating = rating
        self.reviews = reviews
 
    def relevance_score(self):
        # Custom business logic: rating weighted by review volume
        return self.rating * (1 - 1 / (self.reviews + 1))
 
products = [Product("Widget", 9.99, 4.5, 200), Product("Gadget", 14.99, 4.8, 10)]
sorted(products, key=Product.relevance_score, reverse=True)

Passing Product.relevance_score as an unbound method works because Python will call it with each product instance as the argument. This keeps your sort logic encapsulated in the class where it belongs, rather than scattered through your sorting calls.

Search Strategies: Finding Your Needle

Searching is the counterpart to sorting. Once your data is organized, finding what you need becomes tractable.

Linear Search (The Obvious Way)

Most developers reach for if x in list. It works, it's readable, but it's slow for large datasets. Understanding why helps you recognize when it matters and when it doesn't.

numbers = list(range(1000000))
 
# Linear search: O(n), checks every element in worst case
if 999999 in numbers:  # Fast O(1) average lookup
    pass
if 1 in numbers      # Slow (found at start... wait, no, fast)
if 1000001 in numbers  # Slowest (checks all million elements)

The "in" operator iterates from the start until it finds a match (or exhausts the list). Average case? Half the list. Worst case? The whole list.

This works fine for small datasets. For large ones, it's a performance killer.

Binary Search: The bisect Module

If your data is sorted, you can use binary search. Python's bisect module implements this elegantly. Binary search works by repeatedly cutting the search space in half, compare the middle element, and based on whether your target is larger or smaller, discard the half that can't contain it. Each comparison eliminates half the remaining candidates.

import bisect
 
numbers = sorted([3, 1, 4, 1, 5, 9, 2, 6])
# numbers is now [1, 1, 2, 3, 4, 5, 6, 9]
 
# Find the insertion point for 5
index = bisect.bisect_left(numbers, 5)  # 4 (insert at position 4 to keep sorted)
 
# Check if value exists
if numbers[bisect.bisect_left(numbers, 5)] == 5:
    print("Found 5!")

bisect_left returns the leftmost position where the value would be inserted. bisect_right returns the rightmost. This distinction matters when your sorted list contains duplicates, bisect_left gives you the index of the first occurrence, bisect_right gives you the index just after the last occurrence.

from bisect import bisect_left, bisect_right
 
numbers = [1, 2, 2, 2, 3, 4, 5]
 
bisect_left(numbers, 2)   # 1 (first position for 2)
bisect_right(numbers, 2)  # 4 (position after the last 2)
 
# Count occurrences
left = bisect_left(numbers, 2)
right = bisect_right(numbers, 2)
count = right - left  # 3

Why binary search? O(log n) vs. O(n). For a million elements, binary search does ~20 comparisons. Linear search does ~500,000 on average. That's not a small difference, it's the difference between a search that feels instant and one that makes your UI stutter.

import bisect
 
# Real-world example: find all users with score >= 85
users_by_score = sorted(users, key=itemgetter("score"))
cutoff_index = bisect.bisect_left(users_by_score, 85, key=itemgetter("score"))
high_scorers = users_by_score[cutoff_index:]

The key parameter in bisect (Python 3.10+) lets you use the same key extraction logic as sorting. This is a relatively recent addition that makes bisect far more practical for real-world data, previously you'd need to maintain a separate sorted list of just the comparison values, or pre-sort into simple numbers.

Efficient Filtering Patterns

Filtering is not just about correctness, it's about choosing the right tool for your data size and access pattern. Python gives you four main approaches, and picking the wrong one for your context is the most common source of unnecessary memory pressure and slow iteration in Python code.

The most important concept to internalize is the difference between eager and lazy evaluation. Eager evaluation computes all results immediately and stores them in memory. Lazy evaluation computes results one at a time, on demand. For small datasets, the distinction barely matters. For large ones, it's the difference between a script that runs fine and one that consumes 4GB of RAM trying to load a log file.

List comprehensions are eager, they build a complete list in memory before returning anything. Generator expressions are lazy, they produce values one at a time and hold only one value in memory at a time. The syntax is nearly identical, which makes it easy to switch between them once you understand which context calls for which approach.

# Eager: entire filtered list lives in memory at once
filtered_list = [x for x in huge_data if condition(x)]
 
# Lazy: values produced one at a time, minimal memory footprint
filtered_gen = (x for x in huge_data if condition(x))

The rule of thumb: use a list comprehension when you need to access the results multiple times or by index. Use a generator when you're going to iterate through the results exactly once, feeding them into another function, writing them to a file, or piping them through more transformations.

Filtering: filter() vs. Comprehensions vs. Generators

Filtering is about selecting elements that match a condition. Three main approaches exist, and understanding when to use each separates competent developers from great ones.

The Classic: filter() with Functions

filter() takes a function and an iterable, returning elements where the function returns True. It's the oldest approach, inherited from functional programming traditions, and it has a specific use case where it shines.

def is_even(x):
    return x % 2 == 0
 
numbers = [1, 2, 3, 4, 5, 6]
evens = list(filter(is_even, numbers))  # [2, 4, 6]

It works, but it's verbose for simple conditions. Plus, filter() returns an iterator, not a list, so you need to wrap it in list() if you want a concrete sequence.

The Pythonic: List Comprehensions

List comprehensions are the idiomatic Python way to filter. They read naturally in English, "give me x for each x in numbers where x is even", and they support transformation and filtering in a single expression.

numbers = [1, 2, 3, 4, 5, 6]
evens = [x for x in numbers if x % 2 == 0]  # [2, 4, 6]

Faster to write, easier to read, and marginally faster to execute. They're also more flexible, you can transform while filtering:

doubled_evens = [x * 2 for x in numbers if x % 2 == 0]  # [4, 8, 12]

Try that with filter() and you'll need nested calls or intermediate variables. Comprehensions win here unambiguously. The Pythonic guidance from PEP 8 and Python's own documentation leans toward comprehensions over filter() for readability reasons, and the performance difference (though small) also favors comprehensions.

The Lazy: Generator Expressions

For large datasets where you don't need all results upfront, generator expressions are memory-efficient. They look just like list comprehensions, same syntax, same conditions, same transformations, but with parentheses instead of brackets, and fundamentally different execution behavior.

evens_gen = (x for x in numbers if x % 2 == 0)
# Computes elements on-demand, not all at once
 
for even in evens_gen:
    print(even)  # 2, then 4, then 6 (computed one at a time)

The difference? Parentheses instead of brackets. This doesn't create a list in memory; it creates a generator that yields values on demand.

When to use each:

• filter(): Rarely. Use comprehensions instead. The one exception is when you already have a named function and passing it directly is more readable than wrapping it in a comprehension.
• List comprehensions: When you need all results immediately and the dataset fits in memory.
• Generator expressions: When processing large datasets or piping results through multiple operations.

# Memory-efficient pipeline
large_file = open("huge_log.txt")
errors = (line for line in large_file if "ERROR" in line)
critical_errors = (line for line in errors if "CRITICAL" in line)
 
for error in critical_errors:
    process(error)  # Never stores all errors in memory

This pipeline reads one line at a time, filters it through two conditions, and processes it, all without ever holding more than one line in memory simultaneously. If your log file is 10GB, this approach works fine. A list comprehension version would try to load the entire file before processing a single line.

map(): Transform Everything

map() applies a function to every element. Like filter(), it returns an iterator. And like filter(), it's usually better replaced by a comprehension, but it has its moments.

numbers = [1, 2, 3, 4, 5]
squared = list(map(lambda x: x ** 2, numbers))  # [1, 4, 9, 16, 25]

But again, comprehensions are cleaner:

squared = [x ** 2 for x in numbers]

map() shines when you're applying a pre-existing function without modification. Passing a named function directly to map() avoids creating an anonymous lambda wrapper, which is both cleaner and marginally faster:

from operator import itemgetter
 
people = [
    {"name": "alice", "age": 30},
    {"name": "bob", "age": 25},
]
 
names = list(map(itemgetter("name"), people))  # ['alice', 'bob']
 
# vs. comprehension
names = [p["name"] for p in people]

Both work. The comprehension is more readable; map() with itemgetter is slightly faster for large datasets (no lambda overhead). Choose based on readability in most cases, and only optimize toward map() if profiling shows it matters.

Common Sorting Mistakes

Even experienced Python developers fall into predictable traps with sorting. Knowing these mistakes in advance saves you debugging time and prevents subtle bugs from sneaking into production.

Mistake 1: Sorting a list when you wanted sorted(). The .sort() method mutates in place and returns None. Assigning the result to a variable is a classic error that produces baffling bugs.

# Bug: sorted_names is None, not a sorted list
sorted_names = names.sort()  # WRONG: .sort() returns None
print(sorted_names)  # None
 
# Correct: use sorted() to get a new list
sorted_names = sorted(names)  # Returns a new sorted list

Mistake 2: Comparing incompatible types. Python 3 is strict about type comparisons, you can't sort a list containing both integers and strings. This used to work in Python 2, so developers migrating from older codebases can be caught off guard.

# TypeError in Python 3
mixed = [1, "two", 3]
sorted(mixed)  # TypeError: '<' not supported between instances of 'str' and 'int'
 
# Fix: normalize types with a key function
sorted(mixed, key=str)  # ['1', '3', 'two'] - converts all to string for comparison

Mistake 3: Mutating a list while sorting. If your key function has side effects or if you're modifying the list during iteration, results are undefined. Always sort static data.

Mistake 4: Ignoring stability assumptions. If you're relying on stable sort behavior (elements with equal keys preserving their relative order), make sure you actually need it and aren't accidentally depending on insertion order from a different operation. Python's sort is always stable, but the source of your data might not preserve insertion order the way you expect.

Mistake 5: Using sort() on data you need to keep. This is especially common in functions that receive a list as a parameter, sorting in place modifies the caller's data, which can be a very surprising side effect. When in doubt, use sorted() to work on a copy.

def get_top_users(user_list, n=10):
    # BAD: modifies the caller's list
    user_list.sort(key=attrgetter("score"), reverse=True)
    return user_list[:n]
 
def get_top_users(user_list, n=10):
    # GOOD: works on a copy, caller's list is unchanged
    return sorted(user_list, key=attrgetter("score"), reverse=True)[:n]

Bulk Evaluation: any() and all()

You often need to check if any element matches a condition, or all elements do. Python's any() and all() are built for this, and they're far more efficient than manually filtering and checking the result.

numbers = [2, 4, 6, 8, 9]
 
any(x % 2 == 1 for x in numbers)  # True (9 is odd)
all(x > 0 for x in numbers)       # True (all are positive)
all(x % 2 == 0 for x in numbers)  # False (9 is odd)

Hidden layer: any() returns True as soon as it finds a match; it doesn't evaluate the rest. This is called short-circuit evaluation and it's crucial for performance. Similarly, all() returns False as soon as it finds a non-matching element, it doesn't keep checking after the first failure.

# Generator passed to any() - stops evaluating once True is found
any(expensive_operation(x) for x in huge_list)

If the first element matches, any() never calls expensive_operation() on the remaining millions. This is way faster than filtering and checking length. The generator expression fed to any() produces values lazily, so any() can stop requesting values the moment it gets one that's True.

# Slow: filters the entire list
if len([x for x in numbers if x > 100]) > 0:
    print("Found one!")
 
# Fast: stops as soon as first match is found
if any(x > 100 for x in numbers):
    print("Found one!")

The slow version always processes every element, builds a complete list in memory, then checks if that list is non-empty. The fast version stops the moment it finds one match. For a list where the first matching element is near the beginning, any() might do 1 comparison instead of 10,000.

Top-N Selection: heapq.nlargest() and nsmallest()

Finding the top N elements is common: "Give me the top 5 highest scorers," "Find the 3 slowest queries."

Most developers sort and slice, which is the intuitive approach. Sort everything, take the first N. It works, but it's not optimal, you're doing O(n log n) work when you only need the top few.

users = [User("alice", 95), User("bob", 87), User("charlie", 92)]
top_3 = sorted(users, key=attrgetter("score"), reverse=True)[:3]

This sorts the entire list (O(n log n)) to get 3 results. If you only need the top N and N is small, use heapq.nlargest(). It maintains a heap of size N and streams through the data in a single O(n log k) pass.

from heapq import nlargest
 
top_3 = nlargest(3, users, key=attrgetter("score"))

How much faster? O(n log k) where k is the number of results. For large datasets with small k, this is dramatically faster. The rule of thumb: if k is small relative to n (say, k < n/10), use heapq. If k is large or you need the full sorted order, use sorted().

# Finding top 10 in a million records
# Sorted: 1,000,000 comparisons
# heapq: ~130,000 comparisons
 
from heapq import nlargest
top_10 = nlargest(10, huge_dataset, key=itemgetter("score"))

Similarly, nsmallest() finds the smallest N with the same efficiency advantage. Both functions accept the same key parameter as sorted(), so they integrate seamlessly with your existing extraction patterns.

from heapq import nsmallest
 
worst_3 = nsmallest(3, users, key=attrgetter("score"))

The Advanced: functools.cmp_to_key

Sometimes you need sorting logic that's too complex for key functions. This is rare, but it happens, custom comparison rules, multi-pass logic, weird business requirements.

The key-based approach works well when you can project each element to a single comparable value (or tuple of values). But occasionally, the comparison between two elements depends on both elements in ways that can't be reduced to a simple projection. That's when cmp_to_key becomes necessary.

functools.cmp_to_key converts old-style comparison functions (return -1, 0, or 1) into key functions. The comparison function receives two elements and returns negative if the first should come first, positive if the second should come first, and zero if they're equal, the same contract as C's qsort comparator.

from functools import cmp_to_key
 
def compare_users(user1, user2):
    # Sort by age descending, then name ascending
    if user1.age < user2.age:
        return 1  # user1 comes after user2
    elif user1.age > user2.age:
        return -1  # user1 comes before user2
    else:
        # Ages equal, compare names
        if user1.name < user2.name:
            return -1
        elif user1.name > user2.name:
            return 1
        else:
            return 0  # Equal
 
sorted_users = sorted(users, key=cmp_to_key(compare_users))

This is verbose, but it gives you complete control over comparison logic. Use it only when simple key functions can't express your logic. The performance is also worse than key-based sorting because the comparison function is called O(n log n) times, and each call involves Python's full function dispatch. Key functions are called only O(n) times.

In 90% of cases, a tuple key is cleaner and faster:

sorted(users, key=lambda u: (-u.age, u.name))

Reserve cmp_to_key for genuinely complex comparisons, sorting version strings like "1.10.2" vs. "1.9.1" (where string comparison gives the wrong answer), or implementing custom locale-aware text ordering.

Putting It Together: A Real-World Example

Let's build something realistic: "From a list of user purchases, find the top 5 customers by spending, showing only those who made at least 3 purchases, sorted by spending (high to low)."

This example is worth studying because it chains every concept we've covered: aggregation, filtering with comprehensions, and top-N selection. Notice how each step uses the right tool, there's no premature sorting, no unnecessary list creation, and no over-engineered logic.

from operator import itemgetter
from heapq import nlargest
 
purchases = [
    {"user": "alice", "amount": 120},
    {"user": "alice", "amount": 80},
    {"user": "alice", "amount": 50},
    {"user": "bob", "amount": 200},
    {"user": "charlie", "amount": 90},
    {"user": "charlie", "amount": 75},
    {"user": "david", "amount": 110},
]
 
# Step 1: Group by user (aggregate spending and count)
from collections import defaultdict
 
user_stats = defaultdict(lambda: {"total": 0, "count": 0})
for purchase in purchases:
    user = purchase["user"]
    user_stats[user]["total"] += purchase["amount"]
    user_stats[user]["count"] += 1
 
# Step 2: Filter (at least 3 purchases)
qualifying_users = [
    {"user": user, **stats}
    for user, stats in user_stats.items()
    if stats["count"] >= 3
]
 
# Step 3: Get top 5 by spending
top_5 = nlargest(5, qualifying_users, key=itemgetter("total"))
 
for user in top_5:
    print(f"{user['user']}: ${user['total']} ({user['count']} purchases)")

Output:

alice: $250 (3 purchases)

Each step uses the right tool for the job: aggregation for grouping, comprehension for filtering, nlargest() for top-N selection. No unnecessary sorting, no wasted computation. Bob had the single largest purchase ($200) but only made one transaction, so he's filtered out. Alice's three purchases add up to $250, qualifying her for the top customers list. This is the kind of clean, efficient data pipeline that Python excels at when you know which tools to reach for.

Summary

Sorting, searching, and filtering are the backbone of data manipulation. Master these patterns and you'll write faster, cleaner code:

• Use sorted() with key functions (especially attrgetter and itemgetter) for flexible sorting without lambda overhead.
• Leverage tuple keys for multi-field sorting; let Python's tuple comparison do the work.
• Reach for bisect when you need to search sorted data; binary search is exponentially faster than linear.
• Prefer list comprehensions over filter() for readability and pythonic style; use generators when memory efficiency matters.
• Use any() and all() with generators to avoid filtering unnecessarily; short-circuit evaluation stops early.
• Pick heapq.nlargest() for top-N selection; it's faster than sorting the entire dataset.
• Reserve cmp_to_key for comparison logic that can't be expressed with simple keys.
• Trust Timsort to handle partially-ordered data efficiently; Python's sort is smarter than most people realize.

The hidden layer? These aren't just stylistic preferences. They're performance decisions that compound across your application. A search that takes 0.1 seconds instead of 10 seconds. A filter that processes millions of rows in memory instead of consuming gigabytes. A sort that exploits the partial ordering in your real-world data instead of treating it as random. These patterns are how you go from "this code works" to "this code scales." And as you move deeper into data pipelines, machine learning preprocessing, and AI/ML workflows, where you're routinely operating on datasets with millions of records, getting these fundamentals right isn't optional. It's the foundation everything else is built on.