Have various classes inherit from Generic for type checking

[bradykieffer]

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

Internally we've been using djangorestframework-stubs(link here) and it's been really great at helping us avoid some weird classes of errors. My proposal would be to have the following classes inherit from Generic as they do within djangorestframework-stubs:

• ClassLookupDict
• DataAndFiles
• BaseSerializer
• Field
• RelatedField

This is definitely related to #7385 which added __class_getitem__ to the BaseSerializer class.

Pros

• No longer need to add the somewhat boilerplate-y __class_getitem__ to any generic class
• A class marked as Generic[KeyType, ValueType] will raise an exception if not typed with two typed parameters
• It's in the standard library, I would argue it's the more idiomatic approach to typing
• Generic was introduced in Python 3.5, which is the oldest supported version of Python with DRF
• There are various checks within the internals of Generic to ensure that type annotations are indeed valid types

Cons

• Muddling typed code with untyped code - bitrot could occur because mypy checks aren't enforced on DRF
• Python versions pre-3.7 used a different metaclass for Generic, so we'd need special handling for as long as Python 3.5 and 3.6 are supported by the project
• There's some potentially un-intuitive behavior with MyClass[int] not being the same as MyClass (which definitely feels correct) and it breaks current functionality

I have a patch that I'll link to this ticket, I don't think there's really a burden on implementation here 😄

[xordoquy]

hey @carltongibson, what's the position on Dango about typing ?

[carltongibson]

@xordoquy Currently we're not adding type hints.

We added a couple of these class get item methods after some consideration. There's now a suggestion (from @bradykieffer) to add some more. I'm sceptical about that, as it was specifically discussed in the original pass, and said not to be needed.

I'm currently trying to work out if there's a way around adding, essentially no-op, base implementations of these methods. It seems to me to be a source of boilerplate that should be pushed back upstream with the message Do better.

Ref subclassing from Generic there would be no way without an entire reappraisal of the previous discussion, for which I can't see the state of the art has changed to justify. (?)

Again here, why aren't we pushing back to the typing community? Is adding all this cruft really the best we can do? Is it really necessary?

In all the PEPs typing was meant to be optional, not even required by convention, and yet it seems to be failing on that. Multiple requests to add hints, otherwise we can't X or Y or Z. Why aren't we pushing that back to the typing community?

[bradykieffer]

@carltongibson I get where you're coming from, I just had these patches locally so figured I would push them up for comment instead of nuking the code. I'm 100% fine with these patches getting rejected, I just thought that inheriting from generic would be a better solution than having a no-op __class_getitem__ (I would even support just a hard no on that for the time being). Until there's better clarity on where typing will go we can just ignore this.

In the meantime, to save you sanity, could we link to the issues I raised + the mailing list on typing somewhere so that other people don't submit similar patches?

[carltongibson]

Hey @bradykieffer. Sure yes!

We've been round the block a few times here over the last few days. I'm pretty sure you understand my doubts, and I'm genuinely interested to see what the recommended approach would be... -- Maybe a few "hey this isn't really working for us as described" might lead to better solutions, we might hope. 🙂

Thanks for your concern and input!

[bradykieffer]

Hopefully when everything calms down some day we can come up with a path forward on this at PyCon 😄 . Where would you want that type of note? In the docstring for the currently implemented __class_getitem__ methods?

[carltongibson]

@bradykieffer Sounds as good a place as any, yes.