Typing support for Request & Response storages

[gsoldatov]

Is your feature request related to a problem?

Currently, type hinting for items inside Application context storage can be done, using AppKey. Adding the same feature to Request & Response classes would be useful as well.

Describe the solution you'd like

1. Update implementations of MutableMapping in corresponding classes, similarly to how it's done in Application.
2. Since AppKey will be used there, rename it to a more corresponding name (StorageKey?).
3. Keep AppKey as an alias to the new name to avoid introducing a breaking change (with a deprecation warning, perhaps).
4. Update tests & docs.

Describe alternatives you've considered

Related component

Server

Additional context

No response

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[Dreamsorcerer]

We could also consider adding a separate name to avoid mixing keys between Application and Request.

[gsoldatov]

@Dreamsorcerer, that would remove the need for renaming & deprecating. On the other hand, I'm not sure if it's worth having 3 separate entities doing the same thing, instead of 1, when you can separate them simply by using different names or files. It's probably better if you or other folks, who are more familiar with the library and it's consumers, than me, make the final call on this one.

If there are no other considerations, I could make a PR for the issue.

[Dreamsorcerer]

I'm not sure if it's worth having 3 separate entities doing the same thing

I think we could just alias them with NewType. My thinking is that it'd avoid a key that exists on the Application being accidentally used on the Request where it'd produce a KeyError, marginally improving type safety.

If there are no other considerations, I could make a PR for the issue.

Yeah, feel free. The reason I didn't include them originally was to give some chance for AppKey to be proven and gauge demand.

[gsoldatov]

In that case, adding a base class with existing AppKey logic and sub-classing it multiple times should be better, unless I'm missing something.

NewType can be used in two ways, both of which have problems:

1.  # If we derive other key types from AppKey
    RequestKey = NewType("RequestKey", AppKey)
   
    # this will force a more complex & inconsistent syntax for RequestKey:
    some_request_key = RequestKey(AppKey("some_request_key", SomeClass))
   
    # and won't prevent us from using RequestKey on the Application storage

2.  # If we add a base class and alias it with NewType
    class BaseKey:
        ... # existing AppKey logic moves here
   
    AppKey = NewType("AppKey", BaseKey) 
   
    # this would change the way AppKey instances are created
    some_app_key = AppKey(BaseKey("some_app_key", SomeClass))

[Dreamsorcerer]

In that case, adding a base class with existing AppKey logic and sub-classing it multiple times should be better, unless I'm missing something.

Yeah, looks like that'd make more sense.