mirror of
https://github.com/astral-sh/ruff
synced 2026-01-06 06:04:16 -05:00
cfbd42c22a
## Summary Support `dataclass_transform` when used on a (base) class. ## Typing conformance * The changes in `dataclasses_transform_class.py` look good, just a few mistakes due to missing `alias` support. * I didn't look closely at the changes in `dataclasses_transform_converter.py` since we don't support `converter` yet. ## Ecosystem impact The impact looks huge, but it's concentrated on a single project (ibis). Their setup looks more or less like this: * the real `Annotatable`:d7083c2c96/ibis/common/grounds.py (L100-L101)* the real `DataType`:d7083c2c96/ibis/expr/datatypes/core.py (L161-L179)* the real `Array`:d7083c2c96/ibis/expr/datatypes/core.py (L1003-L1006)```py from typing import dataclass_transform @dataclass_transform() class Annotatable: pass class DataType(Annotatable): nullable: bool = True class Array[T](DataType): value_type: T ``` They expect something like `Array([1, 2])` to work, but ty, pyright, mypy, and pyrefly would all expect there to be a first argument for the `nullable` field on `DataType`. I don't really understand on what grounds they expect the `nullable` field to be excluded from the signature, but this seems to be the main reason for the new diagnostics here. Not sure if related, but it looks like their typing setup is not really complete (https://github.com/ibis-project/ibis/issues/6844#issuecomment-1868274770, this thread also mentions `dataclass_transform`). ## Test Plan Update pre-existing tests.