Differences with the official Redis Python client

  • Asynchronous operation:

    • The official client uses asyncio directly, whereas this implementation leverages AnyIO for compatibility with both Trio as well as asyncio.

    • This implementation leverages structured concurrency, making it more robust against cancellation and unexpected problems.

  • 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 the decode 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 or bytes.

  • Publish/subscribe:

  • Pipelines and transactions:

    • Pipelines and transactions are clearly separated from each other, created via either RedisClient.pipeline() or RedisClient.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.