Use __new__() instead of __init__() in serializers - #315

This has been in the back of my mind also. It would be great if this works.

AFAIK def __new__(...) -> ListSerializer is not allowed: mypy requires __new__ return type to be a subclass of the class being defined. There's a discussion about this somewhere in mypy issues or PRs, I couldn't find it right now.

But I think it's possible to convince mypy developers to change this requirement.

Please add a test case demonstrating whether this works or not.

The CI errors will be fixed in #316.

AFAIK def __new__(...) -> ListSerializer is not allowed: mypy requires __new__ return type to be a subclass of the class being defined. There's a discussion about this somewhere in mypy issues or PRs, I couldn't find it right now.

Well ListSerializer is a subclass of BaseSerializer, so this should be alright I guess. Will add tests

EDIT: This is not the case for ModelSerializer, so mypy indeed complains about this:

error: Incompatible return type for "__new__" (returns "ListSerializer[_MT]", but must return a subtype of "ModelSerializer[Any]")

So I've added a type: ignore in the meanwhile

Ok this seems to work fine when using BaseSerializer:

IntBaseSerializer = serializers.BaseSerializer[int]
test_serializer = IntBaseSerializer([1, 2], many=True)
reveal_type(test_serializer) # N: Revealed type is "rest_framework.serializers.ListSerializer[builtins.int]"

But when defining a custom serializer:

class TestSerializer(serializers.Serializer[int]):
    pass

test_serializer = TestSerializer(instance=[1, 2], many=True)
reveal_type(test_serializer) # N: Revealed type is "main.TestSerializer"

We get the wrong type, possibly because mypy isn't using the __new__ overload defined in BaseSerializer. But I suspect this might be because ListSerializer isn't a subclass of TestSerializer, so mypy isn't giving the correct type.

I did some tests locally, and it seems that this issue is specific to mypy:

from __future__ import annotations

class A:
    def __new__(cls) -> B:
        return B()

class B(A):
    pass

class C(A):
    pass

a = C()
reveal_type(a) # Revealed type is "C", but got B with pyright (Pylance)

I'll open a ticket @mypy, and I think this could be an opportunity to discuss what you said @intgr about the requirement that the return type must be a subclass of the class being defined

I found there's already an open mypy issue about this: python/mypy#8330

I think this is now unblocked via python/mypy#21441 as of mypy 2.1 or 2.2

mypy_primer

Compared DRF stubs and plugin at d7ece7f with its target-branch parent. Differences are advisory.

Python 3.11

No diagnostic differences.

Python 3.12

No diagnostic differences.

Python 3.13

No diagnostic differences.

Python 3.14

No diagnostic differences.

Python 3.15

No diagnostic differences.

Full comparison and diagnostic artifacts

We unfortunately still need to work around Mypy not following the spec, but the workaround is straightforward.

I'm not sure if this is safe to get, this may create regressions for users subclassing the serializers and overridding __init__(), calling super().__init__(), etc. It's been a while since I've used Django so I don't remember the potential scenarios where this could create issues.

I just merged CI pyright checking to master #1112 & then merged this branch with master.