Can you explain why this is useful?

@tomchristie I've updated the PR description with more details.

To carry on the conversation from#7385. The types are being used to infer and check the types returned from methods like:get_queryset(),get_object(), etc. With it, we don't need to cast into the correct return types as it can be accurately inferred.

Django has already shipped subscription for QuerySets and other classes which helps avoid the need for monkey patching, but DRF is still missing some key classes.

Rebased to ensure the tests pass.

Not to be a pain, but could another reviewer such as@auvipy take a look at this? We're upgrading to the latestmypy anddjangorestframework-stubs, and this would be great to get implemented to save a lot of repeat code (DRY!).

Thank you!

By making these classes generic, type checkers can more easily do their job when working with DRF classes.

• Could you show me a concrete type-checking issue that this change resolves?
• Is this only useful together with thedjango-restframeworkstubs package?
• Django doesn't appear to have adopted__class_getitem__ for it'sgeneric views or forQuerySets and Managers. I'd normally expect us to follow Django's lead on this kind of design issue. Is there any context we can see there involving similar design discussions against the Django project?

By making these classes generic, type checkers can more easily do their job when working with DRF classes.

• Could you show me a concrete type-checking issue that this change resolves?

It doesn't solve a type-checking issue per se, it solves a problem that occurs when you try to monkey-patch type support. Will try to put up an example project to show the issue, but fundamentally the issue is, unlike Django, DRF eagerly loads settings on import which results in improper settings when trying to monkey patch classes too early.

• Is this only useful together with thedjango-restframeworkstubs package?

Yes and no. Today,django-restframeworkstubs provides support for typing where DRF lacks typing support. There's nothing stopping another stubs implementation or for DRF to provide native typing support.

• Django doesn't appear to have adopted__class_getitem__ for it'sgeneric views or forQuerySets and Managers. I'd normally expect us to follow Django's lead on this kind of design issue. Is there any context we can see there involving similar design discussions against the Django project?

Djangodoes support__class_getitem__ forQuerySets,Managers, andForeignKey. It's true that support hasn't been added for generic views, but that's just a matter of someone contributing support, I believe.

@tomchristie here's a test repo exhibiting some issues:https://github.com/jalaziz/drf-test-repo

As it stands, we end up with no pagination because of the eager settings issue (despitepagination being set):

> curl -H 'Accept: application/json; indent=4' http://127.0.0.1:8000/users/[]

For this repo, the workaround is to move the monkey patching to after theREST_FRAMEWORK definition, but that doesn't work for more complicate setups with nested settings files.

Merging the latestmaster branch might resolve the failingpre-commit check...?

all green now! thanks

Not to be a pain, but could another reviewer such as@auvipy take a look at this? We're upgrading to the latestmypy anddjangorestframework-stubs, and this would be great to get implemented to save a lot of repeat code (DRY!).

Thank you!

sorry I missed the notification

@tomchristie I ran into the issue explained in the PR description. Are there any plans to make a release containing this fix?

Or maybe@auvipy can answer the question about a release?

Nope I can't. I don't have release access yet.

It's still not released?