I prefer ABCs beacuse they're explicit. With a Protocol someone reading the code may not know your class is intended to implement an interface in another module or deep in a dependency. Similarly, you can accidentally conform to a Protocol's signature, without conforming to its contract. For example, if a function accepts a

class Image(Protocol):
    def draw() -> None:
        ...

it's obviously not going to make sense with a

class Cowboy:
    def draw() -> None:
         ...

but the type checker would happily accept it.

There are a few issues with the code you showed. I tried to go through those that I thought were most pressing in no particular order.

Avoid nested ABCs if possible

Since AbstractSerializer will be the abstract base class for your custom serializers, I would suggest defining the abstract methods like get_da_name on that class directly instead of having them in another, separate ABC like ThingsToImplement.

It makes the intent clearer because users of that AbstractSerializer will look at it and immediately see the work they will have to do.

The attributes that need to be present on every serializer subclass like constraints don't technically need to be declared on the ABC, but I think it makes sense for the same reason.

The purpose of Protocols

I would argue that the one of the main purposes of Protocol is to simplify doing exactly the things you are doing here. You define common behavior in a protocol that static type checkers can assume is available on a variable annotated with that Protocol.

In your specific case, it is up to you how finely grained your Protocol subclasses should be. If you want to be very pedantic, any Mix-in can have its own corresponding Protocol, but I would argue that is overkill most of the time. It really depends on how complex that "common behavior" becomes, which the Protocol is supposed to encapsulate.

In your example code I would only define one Protocol. (see below)

In addition, Protocol can be used in a generic way, which IMHO fits perfectly into the model serializer context since every serializer will have his instance set as can be seen in the type stubs for ModelSerializer (inheriting from BaseSerializer), which is also generic over a Model-bound type variable.

Allow ABCs to inherit from ConstraintsMixin

Since you set up your __init_subclass__ class method on ConstraintsMixin so strictly, you need to ensure that the actual ABC you want to create (i.e. AbstractSerializer) can inherit from it without triggering the error.

For this you simply add the ABCMeta check to __init_subclass__ first and avoid triggering the error on ABCs.

Use MySerializerProtocol in Mix-ins

Since your Mix-ins assume certain behavior in their instance methods, that is exactly where you can use MySerializerProtocol to annotate the self parameter.

Again, you may consider splitting the Protocol up further, if it gets too complex.

Solve the Metaclass conflict

Luckily, this is very easy in this case, since there are only two non-type Metaclasses involved here, namely the SerializerMetaclass from Django REST Framework and the ABCMeta from abc, and they don't actually conflict as far as I can see. You just need to define your own Metaclass that inherits from both and specify it in your serializer ABC.

Specify Django Model in subclasses

If you go the generic route (which seems more consistent to me), you should specify the concrete Django Model handled by the serializer, when you subclass AbstractSerializer.

If you don't want to go that route, mypy will complain in --strict mode upon subclassing ModelSerializer (that it is missing a type argument), but you can silence that. Also, you can omit the [M] everywhere in the code (see below) and instead just declare instance: Model on MySerializerProtocol.

Fully annotated example code

from abc import ABC, ABCMeta, abstractmethod
from dataclasses import dataclass
from typing import Any, Protocol, TypeVar

from django.db.models import Model
from rest_framework.serializers import ModelSerializer, SerializerMetaclass


M = TypeVar("M", bound=Model)


# Placeholder for a model to be imported from another module:
class ConcreteDjangoModel(Model):
    pass


@dataclass
class Constraints:
    width: int
    height: int


class MySerializerProtocol(Protocol[M]):
    """For type annotations only; generic over `M` like `ModelSerializer`"""
    my_number: int
    constraints: Constraints
    # From ModelSerializer:
    instance: M

    # From AbstractSerializer:
    def get_da_name(self, s: str) -> str: ...
    # From FooMixin:
    def get_foo(self) -> str: ...
    # From AnotherMixin:
    def get_number(self) -> int: ...
    # From ModelSerializer:
    def to_representation(self, instance: M) -> Any: ...


class ConstraintsMixin:
    # Class attributes that must be set by subclasses:
    constraints: Constraints

    def __init_subclass__(cls, **kwargs: Any) -> None:
        if not isinstance(cls, ABCMeta) and not hasattr(cls, "constraints"):
            raise NotImplementedError("Please add a constraints attribute")
        super().__init_subclass__(**kwargs)

    @classmethod
    def print_constraints(cls: type[MySerializerProtocol[M]]) -> None:
        print(cls.constraints.width, cls.constraints.height)


class FooMixin:
    def get_foo(self: MySerializerProtocol[M]) -> str:
        s = "something"
        return self.get_da_name(s) if self.constraints.width > 123 else "Too small to be named"

    def get_bar(self: MySerializerProtocol[M]) -> Any:
        return self.to_representation(self.instance)

    def from_another(self: MySerializerProtocol[M]) -> str:
        return f"from {self.get_number()}"


class AnotherMixin:
    def get_number(self: MySerializerProtocol[M]) -> int:
        return self.my_number

    def from_foo(self: MySerializerProtocol[M]) -> str:
        return f"from {self.get_foo()}"


class AbstractSerializerMeta(SerializerMetaclass, ABCMeta):
    """To avoid metaclass conflicts in `AbstractSerializer`"""
    pass


class AbstractSerializer(
    ABC,
    ConstraintsMixin,
    FooMixin,
    AnotherMixin,
    ModelSerializer[M],
    metaclass=AbstractSerializerMeta,
):
    # Class attributes that must be set by subclasses:
    constraints: Constraints

    @abstractmethod
    def get_da_name(self, s: str) -> str: ...


class MySerializer(AbstractSerializer[ConcreteDjangoModel]):
    my_number: int = 7
    constraints: Constraints = Constraints(1, 2)

    def get_da_name(self, s: str) -> str:
        self.my_number += 1
        return f"hi {s}"

If you have an older Python version (below 3.9 I think), you may need to replace type[MySerializerProtocol[M]] with typing.Type[MySerializerProtocol[M]] in the print_constraints method.

Thanks for the fun little exercise. Hope this helps.

Feel free to comment, if something is unclear. I will try to amend my answer if necessary.

New in Python 3.8:

Some of the benefits of interfaces and protocols are type hinting during the development process using tools built into IDEs and static type analysis for detection of errors before runtime. This way, a static analysis tool can tell you when you check your code if you're trying to access any members that are not defined on an object, instead of only finding out at runtime.

The typing.Protocol class was added to Python 3.8 as a mechanism for "structural subtyping." The power behind this is that it can be used as an implicit base class. That is, any class that has members that match the Protocol's defined members is considered to be a subclass of it for purposes of static type analysis.

The basic example given in PEP 544 shows how this can be used.

Copyfrom typing import Protocol

class SupportsClose(Protocol):
    def close(self) -> None:
        # ...

class Resource:
    # ...
    def close(self) -> None:
        self.file.close()
        self.lock.release()

def close_all(things: Iterable[SupportsClose]) -> None:
    for thing in things:
        thing.close()

file = open('foo.txt')
resource = Resource()
close_all([file, resource])  # OK!
close_all([1])     # Error: 'int' has no 'close' method

Note: The typing-extensions package backports typing.Protocol for Python 3.5+.

There is no such built-in ABC. In fact, every class has this method inherited from object:

The default implementation defined by the built-in type object calls object.repr().

See docs.

In [1]: class Foo: pass

In [2]: str(Foo())
Out[2]: '<__main__.Foo object at 0x7fcf10e219f0>'

In [3]: print(Foo())
<__main__.Foo object at 0x7fcf10e23d00>

In [4]: print(Foo().__str__())
<__main__.Foo object at 0x7fcf10e20d60>

In [5]: print(Foo().__repr__())
<__main__.Foo object at 0x7fcf10e20af0>

In [6]: object().__repr__()
Out[6]: '<object object at 0x7fcf119c6810>'

In [7]: object().__str__()
Out[7]: '<object object at 0x7fcf119c67c0>'