Python decorators for Redis

[gitdevb]

Proposing a native, decorator-based caching layer to redis-py. While redis-py provides excellent low-level commands (get, set, etc.), developers must repeatedly write boilerplate code to handle cache lookups, insertions, and invalidations within their application logic.

Adding built-in decorators would bring standard, Pythonic caching patterns directly into the ecosystem (similar to functools.lru_cache, but backed by Redis).

Proposed API Design

We can introduce a Cache utility class or expand the client to support decorators that manage the CRUD lifecycle of cached data:

1. Standard Fetch & Cache

@Cache.cache(prefix="users", key="user_id", resolver=my_resolver, ex=3600)
def get_user(user_id):
    return db.fetch(user_id)

2. Cache Invalidation / Eviction

@Cache.delete(prefix="users", key="user_id")
def delete_user(user_id):
    db.remove(user_id)

Argument Breakdown

• prefix / key: Defines the Redis key structure (e.g., {prefix}:{key}).
• resolver: A specialized callback function responsible for data serialization and formatting. It intercepts the wrapped function, its positional arguments, and keyword arguments (func, args, kwargs), returning the exact data structure/type optimized for Redis storage.
• **redisargs: Standard keyword arguments passed down directly to the underlying Redis client commands (like ex, px, nx).

Use Cases & Benefits

1. Reduces Boilerplate: Eliminates repetitive if cache_hit: return patterns across user codebases.
2. Separation of Concerns: Moves serialization, encoding, and formatting logic out of core business logic and into the resolver.
3. Declarative Invalidation: Makes cache eviction explicit and readable by tying @Cache.delete directly to data-mutating functions.

[petyaslavova]

Thanks @gitdevb! The blocker here is invalidation correctness: tying eviction to @Cache.delete only works if every write goes through a decorated function in this process. Writes from other clients/services, server-side expiry, and evictions would leave stale entries with no way to reconcile.

redis-py already handles this with built-in client-side caching over RESP3, where the server pushes invalidation messages and entries are dropped automatically regardless of who wrote the key (cache_config=CacheConfig(), see redis/cache.py). A manual decorator gives that up.
If you want to pursue it, a decorator layered on top of that existing mechanism would be a safer direction.