Senior 5 min · March 06, 2026

functools @lru_cache — Cross-User Cache Leak

A @lru_cache on an instance method shared cache across users via identical self — debugging steps and per-instance cache fix prevent this risk.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • lru_cache memoizes function results using a least-recently-used eviction policy
  • partial pre-fills function arguments, creating a new callable with a shorter signature
  • reduce cumulatively applies a function across an iterable, collapsing it to one value
  • wraps copies metadata (name, docstring) from the decorated function to the wrapper
  • total_ordering generates all six comparison operators from __eq__ and one ordering method
  • Performance: lru_cache can reduce execution time from minutes to microseconds for recursive calls
Plain-English First

Imagine you work at a busy coffee shop. Every time someone orders a 'large oat-milk latte', you go through the exact same 12 steps. A smart barista would write those 12 steps on a card, pin it up, and just follow the card — saving brainpower for new orders. Python's functools module is that card rack: it gives you pre-built tools to remember results you've already computed, lock in some arguments ahead of time, and chain operations together — all so you stop repeating yourself and start writing smarter code.

Every Python developer hits a wall where their functions start to feel repetitive, slow, or just clunky. You write the same boilerplate wrapper around a function to add logging. You call the same expensive database query 50 times with the same arguments. You create a dozen tiny one-liner lambdas that all do slightly different versions of the same thing. These aren't signs you're a bad programmer — they're signs you haven't met functools yet.

The functools module ships inside Python's standard library and exists for one reason: higher-order functions. A higher-order function is just a function that either takes another function as input or returns one as output. functools packages up the most useful patterns for working with functions — caching, partial application, reduction, and decoration — so you don't have to reinvent them every project. It's the toolkit that separates code that just works from code that's elegant, fast, and maintainable.

By the end of this article you'll know exactly what lru_cache, partial, reduce, wraps, and total_ordering do, when each one earns its keep, and the subtle traps that catch even experienced developers off guard. You'll walk away with patterns you can drop into real projects today — not toy examples that you'll never use again.

lru_cache — Stop Recomputing Things You've Already Figured Out

LRU stands for 'Least Recently Used'. The idea is simple: the first time you call a function with a given set of arguments, Python runs the function normally and stores the result in a small memory cache. The second time you call it with the exact same arguments, Python skips the function body entirely and hands you the cached answer instantly.

This is called memoization, and it's a game-changer for any function that's expensive to run — API calls, recursive algorithms, database lookups, mathematical computations. The 'LRU' part means the cache has a maximum size (default 128 entries). When it's full, the result that was accessed least recently gets evicted to make room. That's your memory safety net.

The decorator syntax @lru_cache means zero boilerplate. You don't touch the function's logic at all — you just stick the decorator on top. One critical rule though: every argument you pass must be hashable. Lists and dicts can't be cached because they're mutable — Python has no reliable way to use them as a cache key. If you need to cache a function that takes a list, convert it to a tuple first.

fibonacci_with_cache.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import functools
import time

# Without caching this naive recursive fibonacci is catastrophically slow.
# fib(40) makes over 300 million recursive calls.
@functools.lru_cache(maxsize=128)  # Cache up to 128 unique argument combinations
def fibonacci(n):
    """Return the nth Fibonacci number using memoized recursion."""
    if n < 2:
        return n
    # On the second call with the same n, this line never executes — cache takes over
    return fibonacci(n - 1) + fibonacci(n - 2)

# --- Demonstrating the speed difference ---
start = time.perf_counter()
result = fibonacci(50)  # Would take minutes without caching
elapsed = time.perf_counter() - start

print(f"fibonacci(50) = {result}")
print(f"Computed in {elapsed:.6f} seconds")

# lru_cache gives you a built-in stats tool — use it to verify caching is working
cache_info = fibonacci.cache_info()
print(f"Cache hits: {cache_info.hits}")    # How many times cache answered instead of the function
print(f"Cache misses: {cache_info.misses}") # How many times the function actually ran
print(f"Cache size: {cache_info.currsize}") # How many results are stored right now

# Call again with a cached value to see hits go up
_ = fibonacci(50)
print(f"\nAfter second call — Cache hits: {fibonacci.cache_info().hits}")
Output
fibonacci(50) = 12586269025
Computed in 0.000124 seconds
Cache hits: 48
Cache misses: 51
Cache size: 51
After second call — Cache hits: 49
Pro Tip: Use maxsize=None for Unlimited Caching
If you know your input space is small and bounded (like caching results for employee IDs 1–500), use @functools.lru_cache(maxsize=None). This creates an unbounded cache that's also slightly faster because it skips the LRU eviction bookkeeping. Python 3.9+ also gives you the alias @functools.cache as a shorthand for exactly this pattern.
Production Insight
In one project, a lru_cache with maxsize=None on a function called with hundreds of thousands of unique arguments caused memory to grow until the pod was OOM-killed.
Setting an appropriate maxsize and monitoring cache_info().currsize prevents this.
Rule: always bound your cache unless you are absolutely certain the input space is finite.
Key Takeaway
lru_cache gives free speed for pure functions with repeated argument patterns.
Check cache_info() to confirm it's working.
Arguments must be hashable — convert mutable types first.

partial — Pre-Load Arguments So You Don't Repeat Yourself

Here's a scenario: you have a general-purpose function that takes five arguments, but in 90% of your codebase you always pass the same values for three of them. You end up writing the same three arguments over and over, which is noisy, error-prone, and exhausting to change later.

functools.partial solves this by letting you create a new function with some arguments already baked in. The original function stays untouched. You're just creating a specialised version of it with a shorter signature. Think of it like a stamp — you carve the repeated parts into the stamp, then only deal with the parts that change.

This is especially powerful when working with callbacks, event handlers, or any API that expects a function with a specific signature. You can adapt a general function to fit an exact signature by locking in the arguments it already knows. It's cleaner than a lambda, more self-documenting, and plays better with tools like map() and filter() because partial objects are proper callables with introspectable attributes.

partial_application_demo.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
import functools

# A general-purpose logging function with many configurable parameters
def log_message(level, timestamp_format, application_name, message):
    """Write a formatted log line."""
    import datetime
    timestamp = datetime.datetime.now().strftime(timestamp_format)
    print(f"[{timestamp}] [{level}] [{application_name}] {message}")

# In our payments service we always use the same level, format, and app name.
# Instead of passing all four args every single time, we create a specialised version.
payments_logger = functools.partial(
    log_message,
    level="ERROR",                # Locked in — always ERROR for this logger
    timestamp_format="%H:%M:%S",  # Locked in — always this format
    application_name="PaymentsService"  # Locked in
)

# Now we only supply the one argument that actually changes: the message
payments_logger(message="Card charge failed — insufficient funds")
payments_logger(message="Refund processing timeout after 30s")

print()

# --- Another real-world use: adapting functions for map() ---
def apply_discount(price, discount_rate):
    """Return price after applying a percentage discount."""
    return round(price * (1 - discount_rate), 2)

# Black Friday — everything gets a 30% discount
# We lock in the discount_rate so map() only needs to supply price
black_friday_discount = functools.partial(apply_discount, discount_rate=0.30)

original_prices = [99.99, 149.99, 29.99, 199.99]
discounted_prices = list(map(black_friday_discount, original_prices))

print("Original prices: ", original_prices)
print("After 30% off:   ", discounted_prices)

# You can inspect what was locked in — great for debugging
print(f"\nLocked-in keywords: {black_friday_discount.keywords}")
print(f"Underlying function: {black_friday_discount.func.__name__}")
Output
[14:23:07] [ERROR] [PaymentsService] Card charge failed — insufficient funds
[14:23:07] [ERROR] [PaymentsService] Refund processing timeout after 30s
Original prices: [99.99, 149.99, 29.99, 199.99]
After 30% off: [69.99, 104.99, 20.99, 139.99]
Locked-in keywords: {'discount_rate': 0.3}
Underlying function: apply_discount
partial vs lambda — Which Should You Use?
Use partial when you're locking in keyword arguments to an existing function — it's readable, introspectable, and picklable (which matters for multiprocessing). Use lambda when you need a short anonymous transformation that doesn't fit an existing function's signature. If your lambda is just lambda x: some_func(x, fixed_arg=value), that's a perfect partial candidate.
Production Insight
When using partial with positional arguments, the order matters — accidentally locking the wrong positional arg leads to silent data corruption.
Use keyword arguments with partial for clarity and to avoid order-dependent bugs.
Rule: always lock args by name, not position.
Key Takeaway
partial reduces repetition by freezing arguments.
Use keyword args to keep intent clear.
Introspect .func and .keywords to debug what's locked in.

wraps and reduce — The Two Tools You'll Reach for More Than You Expect

functools.wraps is small but critical. Whenever you write a decorator, you wrap one function inside another. Without wraps, the inner wrapper function steals the identity of the original — its name, docstring, and type hints all vanish. This breaks documentation generators, debuggers, logging tools, and anything that introspects function metadata. One line — @functools.wraps(original_function) — copies all that metadata onto your wrapper so the original function's identity is preserved.

functools.reduce is a different beast. It takes a function and an iterable, then applies the function cumulatively: first to elements 1 and 2, then to that result and element 3, and so on until one value remains. It was built-in in Python 2, but Python 3 moved it to functools to discourage overuse — because a for-loop is often clearer. That said, reduce shines when you need to collapse a sequence using a non-trivial combiner function, especially one you've already defined. sum(), max(), and min() cover the obvious cases — reach for reduce when none of those fit.

wraps_and_reduce_demo.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
import functools
import operator

# ── PART 1: functools.wraps ──────────────────────────────────────────────────

def execution_timer(func):
    """A decorator that measures how long a function takes to run."""
    @functools.wraps(func)  # WITHOUT this, wrapper.__name__ would be 'wrapper', not the real name
    def wrapper(*args, **kwargs):
        import time
        start = time.perf_counter()
        result = func(*args, **kwargs)  # Call the original function
        elapsed = time.perf_counter() - start
        print(f"  ⏱  {func.__name__} completed in {elapsed:.4f}s")
        return result
    return wrapper

@execution_timer
def fetch_user_profile(user_id):
    """Simulate fetching a user profile from a database."""
    import time
    time.sleep(0.05)  # Simulated DB latency
    return {"id": user_id, "name": "Alex Rivera", "plan": "premium"}

profile = fetch_user_profile(user_id=42)

# Because we used @wraps, the function's true identity is intact
print(f"Function name:    {fetch_user_profile.__name__}")  # 'fetch_user_profile', not 'wrapper'
print(f"Docstring:        {fetch_user_profile.__doc__}")
print()

# ── PART 2: functools.reduce ─────────────────────────────────────────────────

# Real-world scenario: merge a list of permission dictionaries into one
# Each dict represents permissions granted by a different role
role_permissions = [
    {"read": True,  "write": False, "delete": False},
    {"read": True,  "write": True,  "delete": False},
    {"read": True,  "write": True,  "delete": True },
]

def merge_permissions(accumulated, new_role):
    """Union two permission dicts — True wins over False (most permissive merge)."""
    return {key: accumulated[key] or new_role[key] for key in accumulated}

# reduce applies merge_permissions left-to-right across the list
final_permissions = functools.reduce(merge_permissions, role_permissions)
print("Merged permissions:", final_permissions)

# Classic use: compute a product of a list (no built-in like sum() exists for this)
monthly_growth_rates = [1.05, 1.03, 1.07, 1.02]  # 5%, 3%, 7%, 2% monthly growth
cumulative_growth = functools.reduce(operator.mul, monthly_growth_rates, 1.0)
print(f"Cumulative growth over 4 months: {cumulative_growth:.4f}x")  # ~1.1837x
Output
⏱ fetch_user_profile completed in 0.0501s
Function name: fetch_user_profile
Docstring: Simulate fetching a user profile from a database.
Merged permissions: {'read': True, 'write': True, 'delete': True}
Cumulative growth over 4 months: 1.1837x
Watch Out: reduce with an Empty Iterable Raises TypeError
functools.reduce([]) with no initial value raises TypeError: reduce() of empty iterable with no initial value. Always pass a safe default as the third argument (e.g., functools.reduce(operator.mul, values, 1)) whenever your iterable might be empty. The initial value acts as both a safety net and the identity element for your operation.
Production Insight
Forgetting @wraps in a decorator causes hours of debugging when Sentry or logging shows 'wrapper' instead of the real function name.
Always add @functools.wraps(func) as a reflex.
For reduce, an empty list without initial value crashes production — always test with edge cases.
Key Takeaway
Every decorator needs @wraps to preserve function identity.
Reduce is powerful but risky with empty inputs.
Use reduce only when sum/max/min don't fit.

total_ordering — Write Two Methods, Get All Six Comparisons Free

If you've ever written a Python class that needs to support sorting — think products sorted by price, tasks sorted by priority, events sorted by date — you've probably realised Python wants you to implement up to six comparison methods: __lt__, __le__, __gt__, __ge__, __eq__, and __ne__. Most of that code is painfully repetitive because they're all logically related. If you can say when A < B, Python can mathematically derive the rest.

functools.total_ordering is the decorator that does exactly this. You implement __eq__ and just one of __lt__, __le__, __gt__, or __ge__. The decorator fills in the remaining four for you, inferring them logically. This is genuinely useful when building data classes that don't use Python's dataclass(order=True) shorthand — for example, when your comparison logic is non-trivial or based on computed properties rather than direct field values.

The performance cost is tiny for most use cases, but be aware: the generated methods are slightly slower than hand-written ones because they go through an extra layer of indirection. If you're sorting millions of objects in a tight loop, profile first.

total_ordering_demo.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
import functools

@functools.total_ordering  # Give us all comparison operators from just two methods
class SupportTicket:
    """
    A customer support ticket. Tickets are compared by priority first,
    then by creation time if priorities are equal.
    Lower priority number = higher urgency (1 is most critical).
    """
    PRIORITY_LABELS = {1: "Critical", 2: "High", 3: "Medium", 4: "Low"}

    def __init__(self, ticket_id, priority, created_at):
        self.ticket_id = ticket_id
        self.priority = priority    # 1 = most urgent
        self.created_at = created_at

    def __repr__(self):
        label = self.PRIORITY_LABELS[self.priority]
        return f"Ticket({self.ticket_id}, {label})"

    def __eq__(self, other):
        if not isinstance(other, SupportTicket):
            return NotImplemented  # Let Python handle comparison with other types gracefully
        return (self.priority, self.created_at) == (other.priority, other.created_at)

    def __lt__(self, other):
        if not isinstance(other, SupportTicket):
            return NotImplemented
        # Lower priority number = more urgent = comes first in sorted order
        return (self.priority, self.created_at) < (other.priority, other.created_at)

    # @total_ordering generates __le__, __gt__, __ge__ automatically from __eq__ and __lt__

import datetime

tickets = [
    SupportTicket("TKT-004", priority=3, created_at=datetime.datetime(2024, 6, 1, 10, 0)),
    SupportTicket("TKT-001", priority=1, created_at=datetime.datetime(2024, 6, 1,  9, 0)),
    SupportTicket("TKT-007", priority=2, created_at=datetime.datetime(2024, 6, 1, 11, 0)),
    SupportTicket("TKT-003", priority=1, created_at=datetime.datetime(2024, 6, 1,  8, 0)),
]

# sorted() works because total_ordering gave us all the operators we needed
priority_queue = sorted(tickets)
print("Tickets in priority order:")
for ticket in priority_queue:
    print(f"  {ticket}")

# The generated operators work correctly
print(f"\nTKT-001 > TKT-007?  {tickets[1] > tickets[2]}")  # True — priority 1 beats priority 2
print(f"TKT-004 >= TKT-007? {tickets[0] >= tickets[2]}")  # False — priority 3 is less urgent
Output
Tickets in priority order:
Ticket(TKT-003, Critical)
Ticket(TKT-001, Critical)
Ticket(TKT-007, High)
Ticket(TKT-004, Medium)
TKT-001 > TKT-007? True
TKT-004 >= TKT-007? False
Interview Gold: total_ordering vs dataclass(order=True)
Interviewers love asking about this. Use dataclass(order=True) when your comparison is simply 'compare all fields in declaration order' — it's zero boilerplate. Use total_ordering when you need custom comparison logic, like 'sort by priority first, then by creation time', because dataclasses can't express that without overriding methods anyway.
Production Insight
A team used total_ordering but forgot to return NotImplemented for cross-type comparisons, causing subtle bugs when comparing Ticket objects with integers.
Always include isinstance checks and return NotImplemented for incompatible types.
Rule: the generated operators rely on your __eq__ and __lt__ being correct — test them thoroughly.
Key Takeaway
total_ordering saves boilerplate for custom sorting.
Implement __eq__ and __lt__ correctly.
Return NotImplemented for type mismatches.

cached_property — Lazy Attribute Caching for Expensive Computations

Sometimes you have a class attribute that's expensive to compute and only needs to be calculated once per instance. Think of a complex regex compilation, a database query, or a large calculation based on instance data. You don't want to recompute it every time it's accessed, but you also don't want to precompute it in __init__ if it might not be used.

functools.cached_property is designed for exactly this. It's a decorator that turns a method into a property whose value is computed once on first access and then cached for the lifetime of the instance. Unlike lru_cache, it's tied to the instance and automatically clears when the instance is garbage collected.

Use this for expensive, read-only attributes that are deterministic given the instance's state. It's especially valuable in data science code where you have derived columns, or in ORM models where you join related data lazily.

cached_property_demo.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
import functools
import re
import time

class DataPipeline:
    def __init__(self, raw_data: list):
        self.raw_data = raw_data

    @functools.cached_property
    def cleaned_data(self):
        """Expensive cleaning operation: only computed when first accessed."""
        print("  [CLEANING] Running expensive data cleaning...")
        time.sleep(0.5)  # Simulate heavy processing
        # Remove None values, strip whitespace, lowercase
        return [str(item).strip().lower() for item in self.raw_data if item is not None]

    @functools.cached_property
    def token_pattern(self):
        """Compile a regex pattern once and cache it."""
        return re.compile(r'\w+')

    def search(self, term):
        """Use cached pattern to search in cleaned data."""
        return [item for item in self.cleaned_data if self.token_pattern.search(term)]

pipeline = DataPipeline(['Alice', None, 'Bob', 'CHARLIE', '  dave  '])

# First access triggers cleaning
print("First access of cleaned_data:")
result = pipeline.cleaned_data
print(f"  Result: {result}\n")

# Second access uses cache (no "CLEANING" output)
print("Second access of cleaned_data:")
result2 = pipeline.cleaned_data
print(f"  Result: {result2}\n")

# The pattern is also cached
print("Searching for 'alice'...")
print(f"  Found: {pipeline.search('alice')}")

# cached_property can be reset by deleting the attribute
print("\nDeleting cached_property to force recompute...")
del pipeline.cleaned_data
print("After delete, accessing again:")
result3 = pipeline.cleaned_data
print(f"  Result: {result3}")
Output
First access of cleaned_data:
[CLEANING] Running expensive data cleaning...
Result: ['alice', 'bob', 'charlie', 'dave']
Second access of cleaned_data:
Result: ['alice', 'bob', 'charlie', 'dave']
Searching for 'alice'...
Found: ['alice']
Deleting cached_property to force recompute...
After delete, accessing again:
[CLEANING] Running expensive data cleaning...
Result: ['alice', 'bob', 'charlie', 'dave']
cached_property vs lru_cache on Methods
Use cached_property when you want a single cached value per instance that never changes after first computation. Use lru_cache on methods when you want to cache multiple return values keyed by arguments. Also note: cached_property is not thread-safe — if multiple threads access it simultaneously, the computation may run multiple times. In concurrent code, use @lru_cache on a method or implement your own locking.
Production Insight
A team used cached_property on a method that depended on external state (e.g., database timestamp). The cached value became stale after a background update, and users saw outdated data.
cached_property is for deterministic, immutable-from-instance-perspective values only.
Rule: never use cached_property for values that can change after the instance is created.
Key Takeaway
cached_property caches expensive attribute computations per instance.
It's not thread-safe and not suitable for mutable state.
Delete the attribute to force re-computation.
● Production incidentPOST-MORTEMseverity: high

The Case of the Leaking Cache — Using @lru_cache on an Instance Method

Symptom
After deploying a new feature, users reported seeing other users' account balances on their dashboard. The data was correct for the first few requests but then started mixing across sessions.
Assumption
The team assumed the database query was returning cached results from a shared connection pool. They spent hours investigating transaction isolation levels and connection reuse.
Root cause
The developer had decorated the instance method get_balance(self, user_id) with @lru_cache. The cache key included self (the instance), which is hashable because the PaymentService class defined __hash__. All instances were accidentally the same due to a singleton pattern, so the cache was shared across all HTTP requests. User A's balance for user_id=42 was cached and returned when user B called the same method — because the instance was the same, the key matched.
Fix
Removed @lru_cache from the instance method. Instead, used a class-level cache keyed only on user_id, or moved the caching logic to a standalone function that doesn't take self as an argument.
Key lesson
  • Never use @lru_cache on instance methods unless you explicitly control the hash of self and understand the caching scope.
  • If you must cache per instance, use a per-instance dict (self._cache) and manage it manually.
  • Always verify cache_info().hits and cache_info().misses in staging before assuming caching works as intended.
Production debug guideSymptom → Action guide for common failures4 entries
Symptom · 01
Function returns stale data even though input arguments changed
Fix
Check cache_info(): print(func.cache_info()). If hits are high but data is wrong, you likely have a hash collision or mutable default argument in the key. Verify all arguments are hashable and immutable.
Symptom · 02
Memory usage grows unboundedly over time
Fix
Set maxsize to a reasonable limit (e.g., @lru_cache(maxsize=1024)). If you used maxsize=None, switch to a bounded cache. Monitor func.cache_info().currsize.
Symptom · 03
Unexpected TypeError: unhashable type when calling a cached function
Fix
Convert mutable arguments (list, dict) to immutable equivalents (tuple, frozenset) before passing. For example, list -> tuple(arg) or use a key function.
Symptom · 04
Decorated function shows wrong __name__ and __doc__
Fix
Ensure @functools.wraps(func) is applied before any other decorator. Verify by checking func.__wrapped__ which gives access to the original undecorated function.
★ Quick Debug: functools Caching & DecoratorsUse these commands to diagnose and fix caching and wrapping issues immediately.
Cache seems to not be working (slow performance)
Immediate action
Call func.cache_info() and inspect the hits/misses ratio. If misses are very high, the arguments likely vary too much.
Commands
print(fibonacci.cache_info())
print(f"Hits: {fibonacci.cache_info().hits}, Misses: {fibonacci.cache_info().misses}, Size: {fibonacci.cache_info().currsize}")
Fix now
If misses > hits, consider if caching is appropriate. Increase maxsize or use @lru_cache(maxsize=None) if input space is small and bounded.
TypeError: unhashable type in cached function+
Immediate action
Convert mutable arguments to immutable before passing to the cached function.
Commands
# Example: @lru_cache def process_list(items_tuple): ... # call with tuple(list_value)
# Or use a wrapper that converts: def cached_process(items): return _cached_process(tuple(items))
Fix now
Wrap the function with one that converts mutable types to hashable equivalents (list->tuple, dict->frozenset of items).
Decorator lost function name and docstring+
Immediate action
Check if @functools.wraps was used. Look at func.__wrapped__ to access the original function.
Commands
print(decorated_func.__name__, decorated_func.__doc__)
print(decorated_func.__wrapped__.__name__, decorated_func.__wrapped__.__doc__)
Fix now
Add @functools.wraps(func) inside your decorator's wrapper function, immediately before the wrapper definition.
functools Tools at a Glance
functools ToolWhat It DoesWhen to Use ItKey Limitation
lru_cacheCaches return values keyed by argumentsExpensive pure functions called repeatedly with the same argsArguments must be hashable; methods on mutable objects need care
cache (3.9+)Unbounded lru_cache with no evictionWhen input space is small and known; slightly faster than lru_cacheCan exhaust memory if called with many unique args
cached_propertyCaches computed attribute per instanceSingle expensive computation per instance, accessed multiple timesNot thread-safe; value becomes stale if internal state changes
partialCreates a new callable with pre-filled argumentsAdapting function signatures for callbacks, map(), event handlersPositional arg order matters; easy to accidentally override locked args
wrapsCopies metadata from wrapped function onto wrapperEvery decorator you write — no exceptionsMust be applied to the inner wrapper, not the outer decorator
reduceCollapses a sequence to a single value via cumulative applicationNon-trivial fold operations where sum/max/min don't fitEmpty iterable without initial value raises TypeError
total_orderingGenerates 4 comparison methods from __eq__ + one otherCustom sortable classes without dataclass boilerplateGenerated methods slightly slower than hand-written; needs both __eq__ and one ordering method

Key takeaways

1
lru_cache is free performance for any pure function you call repeatedly
check cache_info() to verify it's actually helping before assuming.
2
partial is cleaner than a lambda when you're locking in arguments to an existing function
it's readable, picklable, and introspectable via .func and .keywords.
3
Every decorator you write must include @functools.wraps(func)
without it you silently corrupt function metadata and break introspection tools.
4
total_ordering earns its keep when you have non-trivial sorting logic in a class
implement __eq__ and __lt__, and you get the other four comparison operators for free.
5
cached_property is perfect for lazy evaluation of expensive attributes but remember it's not thread-safe and shouldn't be used for mutable state.

Common mistakes to avoid

4 patterns
×

Mistake 1: Decorating a method with @lru_cache directly on an instance method

Symptom
The cache is attached to the class, not the instance, so self is used as a cache key. If self is not hashable (most objects aren't), you get TypeError: unhashable type. Worse, if it is hashable, all instances share one cache, leaking data between them.
Fix
Use @functools.lru_cache on standalone functions or static methods. For instance methods, use a third-party library like methodtools, or cache at the instance level with self.__dict__ inside the method body.
×

Mistake 2: Forgetting @functools.wraps inside a decorator

Symptom
All decorated functions appear as 'wrapper' in tracebacks, docs, and logging. help() shows the wrapper's docstring instead of the original function's.
Fix
Add @functools.wraps(func) immediately above the def wrapper line inside every decorator you write. Make it a reflex — it costs one line and prevents hours of confusing debugging.
×

Mistake 3: Using functools.reduce where a simple for-loop or list comprehension is clearer

Symptom
Code reviews where nobody can tell what the reduce is doing without mentally simulating it. Debugging becomes harder because accumulator state isn't explicit.
Fix
Only use reduce when (a) the operation is already a named function like operator.mul, or (b) you're collapsing a list of dicts or objects with a merge function that's clearly defined elsewhere. If your reducer is a multi-line lambda, write a for-loop instead.
×

Mistake 4: Using cached_property on a method that depends on mutable instance state

Symptom
After modifying an attribute that the cached property depends on, the property still returns the old cached value. Users see stale data.
Fix
Either don't use cached_property for values that can change, or manually delete the cached attribute when the dependency changes (del obj.cached_attr). Alternatively, use a regular property with a check on a version counter.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
What is the difference between @functools.lru_cache and @functools.cache...
Q02SENIOR
If you apply @functools.lru_cache to an instance method in a class, what...
Q03SENIOR
Explain what functools.wraps does and what breaks if you forget it — giv...
Q04SENIOR
What is the difference between functools.partial and a lambda function? ...
Q01 of 04SENIOR

What is the difference between @functools.lru_cache and @functools.cache, and when would you choose one over the other?

ANSWER
@functools.lru_cache (default maxsize=128) provides a bounded cache with LRU eviction, preventing unbounded memory growth. @functools.cache (Python 3.9+) is shorthand for @lru_cache(maxsize=None) — an unbounded cache that is slightly faster because it skips eviction bookkeeping. Use cache when you know the input space is small and bounded, use lru_cache when you need a safety limit on memory usage.
FAQ · 5 QUESTIONS

Frequently Asked Questions

01
Is functools.lru_cache thread-safe in Python?
02
What is the difference between functools.partial and a lambda function in Python?
03
When should I NOT use functools.reduce?
04
Can I use functools.cached_property with class methods or static methods?
05
How do I clear or reset a functools.lru_cache?
🔥

That's Functions. Mark it forged?

5 min read · try the examples if you haven't

Previous
Higher Order Functions in Python
11 / 11 · Functions
Next
Classes and Objects in Python