-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
Feature
@dataclass_transform is a PEP-681 feature that is now mostly supported according to #14293. My proposition is to make sure that it can be used inside of a Generic class. What is more, it should handle passing Genaric methods in field_specifiers
, like so:
class F(Generic[T]):
@staticmethod
def field(factory: Callable[[T], V]) -> V: ...
class G(Generic[T]):
@staticmethod
@dataclass_transform(field_specifiers=(F[T].field, ))
def foo(c): ...
@G[int].foo
class A:
x: int = F[int].field(factory=lambda x: x+2))
reveal_type(A.__init__) # Type of "A.__init__" is "(self: A, x: int = lambda x: x + 2) -> None"
Pitch
The current behavior is that if you annotate a static method (let alone a method inside a Generic class) with @dataclass_transform
mypy won't treat it as dataclass-making decorator (see mypy playground). In this regard pyright does a better job as it allows you to do it (see pyright playground).
If the type checker would allow for the aforementioned feature, then this pattern would be possible to implement (using the above defined code):
class UserModel:
id: str
name: str
class ItemModel:
id: str
price: int
@G[UserModel].foo
class User:
id: str = F[UserModel].field(factory = lamda user: user.id)
name: str = F[UserModel].field(factory = lamda user: user.name)
more_data: str
@G[ItemModel].foo
class User:
id: str = F[ItemModel].field(factory = lamda item: item.id)
price: int = F[ItemModel].field(factory = lamda item: item.price)
more_data: str
The type checker should be able to catch type mismatches between the decorator and field, like so:
@G[UserModel].foo
class User:
# Error: F[ItemModel].field found where F[UserModel].field expected
id: str = F[ItemModel].field(factory = lamda item: item.id)
# Error: no field "price" found for user: UserModel
name: str = F[UserModel].field(factory = lamda user: user.price)