Proposed changes regarding generics and symmetry with dictionaries

[swfarnsworth]

I have a few changes in mind, but I wanted to verify that these are changes we'd want before I potentially clutter the commit history with them.

Generics

These two type aliases are currently defined as follows:

RedisKeyType = Union[str, int]
RedisValueType = Union[str, int, float, bool]

If we redefine them using TypeVar then we can have generics for RedisCache and RedisQueue, but that might count as a backwards-incompatible change depending on what the spec is intended to guarantee about those aliases.

Other dict methods

Currently items is the only view method implemented, and I believe keys and values is feasible, though I'm not sure if that affords us any functionality over for key, _ in await cache.items().

increment and decrement returning the new value

This is the change I'm least sure of since it would actually make the API slightly less symmetric with regular dicts, but it might be a nice quality of life feature for increment and decrement to return the new value after performing the increment/decrement operation so that you don't need back-to-back calls to get and set if you need to know what the result is.

If we decide we want that, I suppose this is in a grey area for backwards compatibility since someone might depend on those methods returning None for some reason.

[SebastiaanZ]

We initially designed the RedisCache around the collections.abc.MutableMapping interface, but that did not match well with the commands Redis offers us. That's why we decided to step away from the symmetry with Python's mapping objects and focus on RedisCache being a type of its own.

In short, for the methods you're proposing, you'd still fetch the entire hashset from Redis, but then discard parts of the output internally, but we'd drop half of it. I'm kinda leaning against that, because it associates the RedisCache quite closely to the workings of a dictionary, which is a promise we can't keep.

[SebastiaanZ]

increment and decrement returning the new value

This is included in the new release, which also makes the increment/decrement operations atomic from a Redis point of view.

[swfarnsworth]

Is this a new release of Redis that you're referring to, and is it already in a state that we can migrate to it?

How do you feel about the generics?

[SebastiaanZ]

Increment and decrement now return the new value in version 0.3.0. It's been released to PyPI Thursday, so you should be able to migrate to that version.

Could you explain your idea about generics for the type? The types supported by the framework are specific: By supporting generics on the various Redis types, we may give the impression that we support storing generic types. We don't, we only support the four specific types listed in the alias and we use the aliases to indicate which specific types we expect for the various arguments (and return types).

Now, my experience with generics is limited to the "oh, nice, we can do this in Python now", would the implementation of these generics come on top of the existing implementation just so people can type hint a specific redis cache (e.g., say "this RedisCache maps str -> str only, not all allowed redis types")? What if someone assumes that they'd now be able to add arbitrary types, such as a user-defined type, because they can type hint it using the generic?

[swfarnsworth]

so people can type hint a specific redis cache (e.g., say "this RedisCache maps str -> str only, not all allowed redis types")?

Yes, it would give people the option of specifying which of all redis-compatible types a specific RedisCache is intended to deal with.

What if someone assumes that they'd now be able to add arbitrary types, such as a user-defined type, because they can type hint it using the generic?

Based on my understanding of the specification of typing.TypeVar, we would define (for example) RedisKeyType as typing.TypeVar('RedisKeyType', int, str), and if one attempted to then write cache: RedisCache[dict, str] = RedisCache(), a linter would treat that as problematic.

I can't speak to how often people find the presence of generics misleading about what behavior is legal, though in theory anyone who understands how they work would be able to recognize that only certain types would be valid for RedisKeyType and RedisValueType, respectively.