Providing type information to mixin classes

[ivanrvpereira]

I don't know if this is a bug, but we should be able to provide type information to mixin classes.

I'm using a _Base class to provide type info to the static type checker.
This technique is not elegant but solves all typing problems within the class, but on Pyright (mypy does not complain) it rises another error showed on the screenshot below.

An example of a Django Serializer Mixin

if TYPE_CHECKING:
    _Base = GenericAPIView
else:
    _Base = object


class DetailSerializerMixin(_Base):
    """
    Add custom serializer for detail view
    """

    detail_serializer_class = None
    queryset_detail: Optional[QuerySet] = None

    def get_serializer_class(self):
        error_message = "'{0}' should include a 'detail_serializer_class' attribute".format(
            self.__class__.__name__
        )
        assert self.detail_serializer_class is not None, error_message
        if self._is_request_to_detail_endpoint():
            return self.detail_serializer_class
        else:
            return super().get_serializer_class()

The error:

If this is not the best approach, can you help me find a solution to provide type info?

[erictraut]

The issue is that the symbol TYPE_CHECKING is treated specially by mypy, but pyright doesn't know about it. Out of curiosity, why are you conditionally deriving from GenericAPIView only in the type checking path rather than always deriving from it?

My philosophy with pyright is to always type check the code that will execute at runtime, not some alternative/conditional path that is specific to the type checker.

[ivanrvpereira]

Because this is a mixin (https://en.wikipedia.org/wiki/Mixin) and I want to add this behavior to any class that supports it. It could be the GenericAPIView or any other that behaves like it.

There is a similar thread on mypy: python/mypy#5837

[erictraut]

That approach for mix-ins strikes me as very fragile and ill-advised, but I don't understand your particular use case well enough to suggest a better approach.

I've implemented special-case support for the TYPE_CHECKING to mirror the behavior in mypy. This will be in the next release of pyright.

[erictraut]

Support for TYPE_CHECKING is now added in 1.0.26