-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mypy 0.990 breaks commonly used Protocol definition for dataclasses #14029
Comments
Another related case: https://mypy-play.net/?mypy=master&python=3.10&gist=04ece0675f41515ecf091ba1de914605 class Dataclass(Protocol):
__dataclass_fields__: dict
T = TypeVar("T", bound=Dataclass)
@dataclass
class MyDataclass:
blah: int
#### Example 2
class DataclassSerializer(Generic[T]):
...
class MySerializer(DataclassSerializer[MyDataclass]):
# ^ error: Type argument "MyDataclass" of "Serializer" must be a subtype of "Dataclass" [type-var]
pass |
I think it's correct, and you'll need to add ClassVar. mypy recently started allowing classes as protocol implementations, which you'll probably want to distinguish. See #4536 (comment) which is the reason why I made the change. |
I think the change makes sense and it's more logical to treat |
oxan, could union of two protocols work for giving you a little bit more mypy compatibility? |
Ah yes, something like this seems to work: # for mypy 0.990+
class NewStyleDataclassProtocol(Protocol):
__dataclass_fields__: ClassVar[dict]
# for mypy <0.990
class OldStyleDataclassProtocol(Protocol):
__dataclass_fields__: dict
Dataclass = Union[OldStyleDataclassProtocol, NewStyleDataclassProtocol] Thanks! |
Bug Report
With mypy 0.990 the dataclass
__dataclass_fields__
attribute is now a ClassVar, which mypy considers to be incompatible with an instance attribute. This causes results like:Was this change intentional, do all users of this trick have to change
__dataclass_fields__: dict
toClassVar[dict]
, or is this an unintended result?To Reproduce
https://mypy-play.net/?mypy=master&python=3.10&gist=c3bb7ee9862a0890e905a35dc1fe8209
Expected Behavior
I'm not sure to be honest whether the new behavior is correct or not, wanted to make sure.
Seems to be related to #13721, pinging @hauntsaninja.
The text was updated successfully, but these errors were encountered: