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 combinationsdeffibonacci(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 overreturnfibonacci(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 functionprint(f"Cache misses: {cache_info.misses}") # How many times the function actually ranprint(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 parametersdeflog_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 messagepayments_logger(message="Card charge failed — insufficient funds")
payments_logger(message="Refund processing timeout after 30s")
print()
# --- Another real-world use: adapting functions for map() ---defapply_discount(price, discount_rate):
"""Return price after applying a percentage discount."""returnround(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 debuggingprint(f"\nLocked-in keywords: {black_friday_discount.keywords}")
print(f"Underlying function: {black_friday_discount.func.__name__}")
[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 ──────────────────────────────────────────────────defexecution_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 namedefwrapper(*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
deffetch_user_profile(user_id):
"""Simulate fetching a user profile from a database."""import time
time.sleep(0.05) # Simulated DB latencyreturn {"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 intactprint(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 },
]
defmerge_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.
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 methodsclassSupportTicket:
"""
A customer support ticket. Tickets are compared by priority first,
then by creation time if priorities are equal.
Lower priority number = higher urgency (1is 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 urgentself.created_at = created_at
def__repr__(self):
label = self.PRIORITY_LABELS[self.priority]
return f"Ticket({self.ticket_id}, {label})"def__eq__(self, other):
ifnotisinstance(other, SupportTicket):
return NotImplemented# Let Python handle comparison with other types gracefullyreturn (self.priority, self.created_at) == (other.priority, other.created_at)
def__lt__(self, other):
ifnotisinstance(other, SupportTicket):
returnNotImplemented# Lower priority number = more urgent = comes first in sorted orderreturn (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 correctlyprint(f"\nTKT-001 > TKT-007? {tickets[1] > tickets[2]}") # True — priority 1 beats priority 2print(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
classDataPipeline:
def__init__(self, raw_data: list):
self.raw_data = raw_data
@functools.cached_property
defcleaned_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, lowercasereturn [str(item).strip().lower() for item inself.raw_data if item isnotNone]
@functools.cached_property
deftoken_pattern(self):
"""Compile a regex pattern once and cache it."""return re.compile(r'\w+')
defsearch(self, term):
"""Use cached pattern to search in cleaned data."""return [item for item inself.cleaned_data ifself.token_pattern.search(term)]
pipeline = DataPipeline(['Alice', None, 'Bob', 'CHARLIE', ' dave '])
# First access triggers cleaningprint("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 cachedprint("Searching for 'alice'...")
print(f" Found: {pipeline.search('alice')}")
# cached_property can be reset by deleting the attributeprint("\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.
Add @functools.wraps(func) inside your decorator's wrapper function, immediately before the wrapper definition.
functools Tools at a Glance
functools Tool
What It Does
When to Use It
Key Limitation
lru_cache
Caches return values keyed by arguments
Expensive pure functions called repeatedly with the same args
Arguments must be hashable; methods on mutable objects need care
cache (3.9+)
Unbounded lru_cache with no eviction
When input space is small and known; slightly faster than lru_cache
Can exhaust memory if called with many unique args
cached_property
Caches computed attribute per instance
Single expensive computation per instance, accessed multiple times
Not thread-safe; value becomes stale if internal state changes
partial
Creates a new callable with pre-filled arguments
Adapting function signatures for callbacks, map(), event handlers
Positional arg order matters; easy to accidentally override locked args
wraps
Copies metadata from wrapped function onto wrapper
Every decorator you write — no exceptions
Must be applied to the inner wrapper, not the outer decorator
reduce
Collapses a sequence to a single value via cumulative application
Non-trivial fold operations where sum/max/min don't fit
Empty iterable without initial value raises TypeError
total_ordering
Generates 4 comparison methods from __eq__ + one other
Custom sortable classes without dataclass boilerplate
Generated 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.
Q02 of 04SENIOR
If you apply @functools.lru_cache to an instance method in a class, what problem can occur and how would you fix it?
ANSWER
The decorator includes self in the cache key. If self is not hashable, you get TypeError. If it is hashable (e.g., because the class defines __hash__), all instances share one cache, causing data leakage between objects. The fix is to not use lru_cache on instance methods — either convert the method to a static/class method, or cache manually using an instance-level dict (e.g., self._cache = {}).
Q03 of 04SENIOR
Explain what functools.wraps does and what breaks if you forget it — give a concrete example of the failure.
ANSWER
functools.wraps copies the original function's name, docstring, module, and other metadata onto the wrapper function created by a decorator. If you forget it, introspection tools like help(), Sphinx docs, Sentry error logs, and even Python's own __name__ will show the wrapper's name (e.g., 'wrapper') instead of the original function's name. For example, a @timer decorator without wraps would make all decorated functions appear as 'wrapper' in tracebacks, making debugging confusing.
Q04 of 04SENIOR
What is the difference between functools.partial and a lambda function? When would you prefer one over the other?
ANSWER
Both create callable objects with pre-filled behaviour, but partial locks in specific arguments to an existing named function and is fully introspectable (you can check .func, .args, .keywords). A lambda creates a brand-new anonymous function. Crucially, partial objects are picklable, which means they work with multiprocessing.Pool.map() — lambdas don't pickle and will crash in that context. Prefer partial when you are fixing arguments to an existing function; use lambda for short anonymous transformations that don't fit an existing function's signature.
01
What is the difference between @functools.lru_cache and @functools.cache, and when would you choose one over the other?
SENIOR
02
If you apply @functools.lru_cache to an instance method in a class, what problem can occur and how would you fix it?
SENIOR
03
Explain what functools.wraps does and what breaks if you forget it — give a concrete example of the failure.
SENIOR
04
What is the difference between functools.partial and a lambda function? When would you prefer one over the other?
SENIOR
FAQ · 5 QUESTIONS
Frequently Asked Questions
01
Is functools.lru_cache thread-safe in Python?
Yes — lru_cache uses a reentrant lock internally to protect the cache dictionary in multi-threaded environments. That said, the lock can become a bottleneck under very high concurrency because threads queue up to access the cache. For CPU-bound parallel workloads, consider process-level caching strategies instead.
Was this helpful?
02
What is the difference between functools.partial and a lambda function in Python?
Both create callable objects with pre-filled behaviour, but partial locks in specific arguments to an existing named function and is fully introspectable (you can check .func, .args, .keywords). A lambda creates a brand-new anonymous function. Crucially, partial objects are picklable, which means they work with multiprocessing.Pool.map() — lambdas don't pickle and will crash in that context.
Was this helpful?
03
When should I NOT use functools.reduce?
Avoid reduce whenever a built-in (sum, max, min, any, all) already covers the operation, or when the reducer function is complex enough that a for-loop with a named accumulator variable would be easier to read and debug. Guido van Rossum himself moved reduce out of Python 3 builtins because overuse made code harder to reason about — that's a strong signal.
Was this helpful?
04
Can I use functools.cached_property with class methods or static methods?
No — cached_property is designed for instance methods only. It stores the cached value on the instance's __dict__, which doesn't work on class methods (which receive cls) or static methods. For class-level caching, use @lru_cache on a class method, or create a class-level dictionary manually.
Was this helpful?
05
How do I clear or reset a functools.lru_cache?
Call func.cache_clear() on the decorated function. This removes all cached entries and resets hit/miss counters. For example, fibonacci.cache_clear(). This is useful in tests or after configuration changes.