Differences with the official Redis Python client
Asynchronous operation:
Supported features:
Currently, this implementation only supports a narrow subset of features provided by the official client. In particular, Redis Stack features are absent.
String handling: Byte string (
bytes
) to unicode string (str
) decoding is controlled on the level of individual method (via thedecode
argument), rather than the client object, as in the official client. This has three advantages:It allows the Redis client object to be shared between multiple unrelated code bases working together in the same application.
It allows developers to opt out of unicode decoding on a case-by-case basis when receiving binary data (e.g. when using Redis to cache serialized objects).
It allows static type checkers to determine the exact return values of string-returning commands, whereas in the official client, all such methods are typed as returning either
str
orbytes
.
Publish/subscribe:
In the official client, you first create a “pubsub” object and then use that to make subscriptions. In this implementation, you call
RedisClient.subscribe()
,RedisClient.ssubscribe()
orRedisClient.psubscribe()
and use them withasync with
and then iterate through them to receive the push events.
Pipelines and transactions:
Pipelines and transactions are clearly separated from each other, created via either
RedisClient.pipeline()
orRedisClient.transaction()
, whereas in the official client they are lumped into the same pipeline class, differentiated via a flag.There is currently no way to leverage the
WATCH
command in this implementation.Commands are queued with synchronous calls, unlike with the official async client.
Queuing a command in this implementation gives you a handle that lets you check the result after execution, while in the official client, you get all the results back as a list from the
execute()
call.