I have made things!

Requires django-stubs to be released with mypy 0.950 support (https://github.com/typeddjango/django-stubs/pull/939)

I think it also depends on #213, mypy 0.950 doesn't like django-stubs 1.10.1.

Related issues

• Depends on: #213
• Depends on: https://github.com/typeddjango/django-stubs/pull/939

Hi @Goldziher, in your https://github.com/typeddjango/djangorestframework-stubs/pull/94/files you made a lot of improvements to the serializer's types, so I decided to try it in one of my projects and provide some feedback.

First of all thanks for your work it looks like you spent a lot of time working on that pr, the main problem that I see right now is that types become too specific, for example serializer generic signature https://github.com/typeddjango/djangorestframework-stubs/blob/master/rest_framework-stubs/serializers.pyi#L94 class BaseSerializer(Generic[_VT, _DT, _RP, _IN], Field[_VT, _DT, _RP, _IN]): with such signature I have to provide 4 types or not provide types at all so all generics become Any. Here why I think _VT, _DT and _RP are not that useful

• _VT - used in initial and default attributes, you can easily provide that in code when needed

class S(Serializer):
     initial: InitialType
     default: DefaultType

     def __init__(..., initial: IntitialType, defautl: DefaultType,...):

• _DT - data that seriailzer will validate, it should be typed as Any or maybe Union[dict, list], because main use case is that you accept anything as data and want to validate that it valid input

• _RP - representation method result, not sure why we should care about that type, it mostly internally used inside def data so it's better to have data return specific type instead of Any, anyway no reason to make it generic, you can easily override method return signature if you need it.

Basically when I work with serializer I care about these things:

• instance type
• result of the serialization serializer.data
• result of the validation serializer.validated_data

Of all of that cases I would argue that only instance type worth to make generic, because it used in signatures of a lot of methods, while you can always override result signature for data or validated_data methods when needed. So I would change signature to Seriailizer(Generict[_IN]) until mypy has support for default values for generic eg. Serailizer(Generic[_IN, _DT = Any, ...]).

Another problem is that these methods + def validate works with OrderedDict, first of all that should be a dict because the ordering of the dict is not important for these methods, second is that user can write serializer(many=True) and these methods now must work with List[dict] instead of dict. So I would change their signature back to:

    def update(self, instance: Model, validated_data: Any) -> Any: ...
    def create(self, validated_data: Any) -> Any: ...
    def save(self, **kwargs: Any) -> Any: ...
    def validate(self, attrs: Any) -> Any: ...

I'm happy to discuss these and provide more feedback as soon as we get these things resolved, right now after drf-stubs update I get 220 type errors and problems described above make a big portion of it.

This PR is a major overhaul of the typings in this package. What it does:

1. It syncs and adds almost all missing data from the latest version of the DRF
2. It fixes a lot of the previous typings and updates these to be in sync with the DRF
3. It adds significant improvements to typings - especially using generics for fields, relations and serialisers
4. It adds testing against the DRF test suit
5. It fully debugs the typings of this package and all changes against this test suit (this took me more than 30 hours to do).

What remains to be done:

1. finish fix travis

• Fixes the following issue when you use self.client in any DRF test class Incompatible types in assignment (expression has type "HttpResponse", variable has type "Response")

Description

I've recently upgraded to the latest master of both repos and ran into the above error. The issue seems to be that DRF APITestCase classes seem to be revealing type as HttpResponse instead of drf Response. The correctclient_class type hints exist here. But this alone doesn't seem enough to correctly type check all uses of the client. If one uses self.client inside a test method the client class still gets Client class instead of APIClient, because of the django-stubs here.

This new error could be because of the recent changes to django-stubs that have surfaced additional type hints?

Sample Test case

from rest_framework.test import APITestCase
from rest_framework.response import Response

class MyTest(APITestCase):
    ...
    
    def test_method(self):
       # error:
       # Incompatible types in assignment (expression has type "HttpResponse", variable has type "Response")
       response: Response = self.client.post("/dummy")

client_class is explicitly set to APIClient in rest_framework/test.py, but I suppose that the client is created dynamically, thus drf-stubs have no idea that it should be an APIClient and not a Client warning me about response.data and client.force_authenticate.

@sobolevn Let's make a release, there's a significant number of things in master, including full compatibility with django-stubs 1.13.0, Python 3.10 and mypy 0.991.

I have created draft release notes at https://github.com/typeddjango/djangorestframework-stubs/releases

This PR also tweaks a few places in documentation:

• Updated Python compatibility in setup.py and README.
• Removed DRF version from README -- it has been out of date for a while.
• Added link to typeshed coding conventions that's now enforced by flake8-pyi

I have made things!

This is a PR similar to https://github.com/typeddjango/django-stubs/pull/1253, only for rest_framework-stubs.

All statements that are unclear on how to proceed are marked with # noqa: in the code, with the exception of compat.pyi, which has additional rules turned off in setup.cfg.

There are some low-hanging fruits to fix, e.g. https://github.com/typeddjango/djangorestframework-stubs/blob/89f8925c67027a759ca08c3643934aa8de107859/rest_framework-stubs/fields.pyi#L350 should obviously be

max_whole_digits: int | None

or https://github.com/typeddjango/djangorestframework-stubs/blob/89f8925c67027a759ca08c3643934aa8de107859/rest_framework-stubs/routers.pyi#L60 which could be set to default_schema_renderers: None, or removed altogether.

I have made things!

Related issues

Closes #230

I'm not absolutely certain the test is in the right place but it does appear to exercise the changed code. Thank you in advance for any feedback!

status.HTTP_200_OK should be Literal[200], not Literal[202]. Fixes #123.

I cannot run pytest because of #124, but I don't see how this could break anything.

Currently a lot of Field's attributes are not exposed in types, eg:

error: "ChoiceField" has no attribute "field_name"
error: "Field" has no attribute "allow_blank"
error: "Field" has no attribute "allow_null"
error: "Field" has no attribute "default"; maybe "get_default"?
error: "Field" has no attribute "read_only"
error: "Field" has no attribute "required"

that cause a lot of headache when serializers modified dynamically.

Bug report

What's wrong

When using mypy with strict=true, it issues the following error: Missing type parameters for generic type "GenericAPIView".

So, I check the type and add it, but I'm now getting a runtime error: TypeError: 'type' object is not subscriptable.

I am using django_stubs_ext.monkeypatch(), which solves the problem for other similar issues.

I haven't test it on its own, but this should suffice, as a reproducible test:

from rest_framework.generics import GenericAPIView

class ShouldWorkView(GenericAPIView[None]):
   ...

How is that should be

The above example should pass, with no issues.

System information

• OS: Arch
• python version: 3.10
• django version: 4.0.7
• mypy version: 0.942
• django-stubs version: 1.12.0

Bumps django-stubs from 1.13.0 to 1.13.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

It would be nice if we could use the classes already defined in generics.py as protocols.

For example, if I want to define a new viewset mixin

class TagModelMixin:
    @action(
        detail=True,
        methods=["PUT"],
        url_path="tag/(?P<slug>[^/.]+)",
    )
    def tag(self, request: Request, slug: str, pk: Any = None) -> Response:
        """Tag an instance with a specific tag"""
        instance = self.get_object()  
        instance.tag.add(slug)
        ...

mypy complains that TagModelMixin does not have a get_object attribute

I think the solution is to define a protocol for the api of GenericAPIView - which is sort of already defined in generics.py

Bug report

What's wrong

It appears that mokeypatching DRF viewsets (as suggested here) breaks the usage of django_filters FilterSets:

# views.py
class DocumentViewSet(viewsets.ModelViewSet[Document]):
    queryset = Document.objects.all()
    serializer_class = DocumentSerializer
    filterset_class = DocumentFilterSet

# settings.py
import django_stubs_ext
from rest_framework import viewsets

django_stubs_ext.monkeypatch(extra_classes=(viewsets.ModelViewSet,))

With this code the DocumentViewSet completely ignores the filters defined in DocumentFilterSet. GET params simply stop working for filtering and the filter UI is completely missing from DRF's HTML view.

Refer to this test in the demo repository. In the original commit, the test passes, but after types are added, the test fails.

How is that should be

DRF filters should continue working after monkeypatching.

System information

• OS: Ubuntu 20.04
• python version: 3.10
• django version: 4.1
• mypy version: 0.991
• django-stubs version: 1.13.0
• django-stubs-ext version: 0.7.0

Bug report

What's wrong

The conflict is caused by:
    django-stubs[compatible-mypy] 1.13.0 depends on mypy>=0.980
    django-stubs[compatible-mypy] 1.13.0 depends on mypy<0.990 and >=0.980; extra == "compatible-mypy"
    djangorestframework-stubs[compatible-mypy] 1.8.0 depends on mypy>=0.980
    djangorestframework-stubs[compatible-mypy] 1.8.0 depends on mypy<0.1000 and >=0.991; extra == "compatible-mypy"

How is that should be

djangorestframework-stubs[compatible-mypy] 1.8.0 depends on mypy<0.1000 and >=0.991; extra == "compatible-mypy" Why having so much restriction about mypy package version when there is no major changes ?
It should at least match: django-stubs[compatible-mypy] 1.13.0 depends on mypy<0.990 and >=0.980; extra == "compatible-mypy"

System information

• OS: Linux (Fedora 37)
• python version: 3.11
• django version: 4.1.3
• mypy version: ???
• django-stubs version: 1.8.0

I have made things!

Related issues

I didn't create an issue, but it's the mirror of https://github.com/typeddjango/django-stubs/issues/1137, for this repo. There might be more places where the same should be applied, but this resolves my issue.