Version: redis-py 8.1.0, Redis 8.x
Platform: Python 3.14 on macOS/Linux
Description:
The current redis-py README states that redis-py >= 6.0.0 supports Redis 7.2 to current.
Redis 7.2+ supports ZRANGE ... REV, while ZREVRANGE is deprecated:
However, the rank-only reverse path in Redis.zrange() still delegates to zrevrange():
redis.zrange("scores", 0, -1, desc=True)
This sends the following command on the wire:
For the currently supported Redis versions, the expected command would be:
This appears to be a follow-up to the compatibility fix in #1697, which restored support for Redis versions older than 6.2. Those versions are no longer listed in the current supported-version matrix.
Expected behavior:
Could the legacy fallback be reconsidered for the currently supported Redis versions?
Possible approaches:
- Make
zrange(desc=True) send ZRANGE ... REV by default.
- Add an explicit opt-in argument such as
force_zrange=True or use_rev=True.
- Deprecate the legacy fallback and remove it in a future major release.
The current workaround is:
redis.execute_command("ZRANGE", "scores", 0, -1, "REV")
Would a backward-compatible opt-in API be preferred, or is removing the fallback acceptable given the current support matrix?
Version: redis-py 8.1.0, Redis 8.x
Platform: Python 3.14 on macOS/Linux
Description:
The current redis-py README states that redis-py >= 6.0.0 supports Redis 7.2 to current.
Redis 7.2+ supports
ZRANGE ... REV, whileZREVRANGEis deprecated:However, the rank-only reverse path in
Redis.zrange()still delegates tozrevrange():This sends the following command on the wire:
For the currently supported Redis versions, the expected command would be:
This appears to be a follow-up to the compatibility fix in #1697, which restored support for Redis versions older than 6.2. Those versions are no longer listed in the current supported-version matrix.
Expected behavior:
Could the legacy fallback be reconsidered for the currently supported Redis versions?
Possible approaches:
zrange(desc=True)sendZRANGE ... REVby default.force_zrange=Trueoruse_rev=True.The current workaround is:
Would a backward-compatible opt-in API be preferred, or is removing the fallback acceptable given the current support matrix?