Mixin pattern does not play well with slots

从提供的 HasTimestampMixin 和 ConcreteMessage 复现开始，然后运行 mypy，并将其结果与 pyright 和 ty 进行比较。追踪 mypy 如何跨越 slots 和 MRO 检查对带注解属性的赋值；完成的标准是示例在保留具体类的 slot 行为的同时通过类型检查，且不再出现所报告的错误。

I am annotating a large codebase with heavy use of mixin patterns, where classes sharing similar attributes inherit the mixin for additional functionality.

One pattern in particular is failing on mypy (but passes on pyright and ty): where slots are involved in the concrete class. Let's look at this MRO, where HasTimestampMixin offers another way of setting the timestamp attribute.

from datetime import datetime


class HasTimestampMixin:
    __slots__ = []

    # Attribute contract: concrete subclasses provide this slot.
    timestamp: str | None

    @property
    def timestamp_dt(self) -> datetime | None:
        if self.timestamp is None:
            return None
        return datetime.fromisoformat(self.timestamp)

    @timestamp_dt.setter
    def timestamp_dt(self, dt: datetime | None) -> None:
        # this line fails with
        # Trying to assign name "timestamp" that is not in "__slots__" of type "repro.HasTimestampMixin"  [misc]
        self.timestamp = None if dt is None else dt.isoformat()


class ConcreteMessage(HasTimestampMixin):
    __slots__ = ["timestamp"]

    timestamp: str | None

    def __init__(self) -> None:
        self.timestamp = None


message = ConcreteMessage()
message.timestamp_dt = datetime(2026, 7, 30)
print(message.timestamp)  # Output: 2026-07-30T00:00:00

Removing the __slots__ in the mixin class fixes the typing issue but breaks the runtime by no longer having slots in the concrete class.