I'm developing a small Python application that interacts with Redis using redis-py, which I believe is the go-to library for this purpose. However, I'm finding the typing in redis-py to be quite frustrating, with many return types being either `Any`, `Unknown`, or `Awaitable[T] | T`. Given Python's strong typing ecosystem, I'm surprised that this is the best Redis library available. Is redis-py really the most popular choice, or are there better alternatives that are better typed and suitable for production use?
5 Answers
It's an open-source library, so if typing is an issue, you can always contribute to fixing it yourself. That said, I have had a pull request out for over a year regarding typing, and there's been no response.
I don't think redis-py is as bad as some are saying. The types you'd expect in Redis are pretty basic, so the lack of strict typing isn't a huge issue. You can define your variables directly when you call functions. Sure, it'd be nice if the typing was better, but if you plan your calls right, you can manage just fine. And yes, I definitely use redis-py in serious projects.
Keep in mind that Redis is fundamentally a key/value store, so the typing issue might not be as critical as with other data types. You should choose how to manage the data you read and write.
Have you looked into the types-redis package? It claims to be a stub package for redis-py, but make sure to check that your version of redis already includes type annotations since version 5.0.0. Otherwise, types-redis might not be necessary anymore.
Good to note! I'll have to uninstall types-redis if I'm using the latest redis-py version.
Yeah, redis-py has its issues. I've had to create a typing.Protocol with proper annotations for the few methods I use and then cast the Redis connection objects to that type. If I were starting a new project, I might consider Valkey and use the Valkey-Glide client instead, but it doesn't support all Redis versions due to being a fork.
I hear you! It's a bummer to have to work around the typing issues instead of just focusing on the app.
That's a solid approach! I've ended up creating my own wrapper around the Redis object too; it makes adding type hints easier and allows for quick changes if I decide to switch to a different key/value store later.
I get your point, but the type hints can be frustrating. I often have to ignore types or cast the async methods because the types are so vague. After recent license changes, I feel less motivated to help improve the library.