dataclass_transform is incredibly finicky

[Aran-Fey]

Since apparently nothing I report is considered a bug, I won't waste my time going into too much detail. But @dataclass_transform() is extremely poorly supported, and the tiniest change can lead to completely different results. Some examples:

@dataclass_transform()
class MetaClassParent(type):
    pass

class MetaClassChild(MetaClassParent):
    pass

class Demo(metaclass=MetaClassChild):
    x: int

Demo(3)  # Error: Expected no arguments to "Demo" constructor

def my_field(
    *,
    init: bool = False,
    my_extra_arg: bool,
) -> Any:
    ...

@dataclass_transform(field_specifiers=(my_field,))
class MyDataClass:
    pass

class Demo(MyDataClass):
    x: int = my_field(my_extra_arg=True)

Demo()  # Signature is *args, **kwargs for some reason

Among other problems that I can't reproduce with a short snippet.

[erictraut]

Moving this to a discussion since it's a question about how to use dataclass_transform rather than a bug report.

[erictraut]

Please refer to the specification in PEP 681.

The @dataclass_transform in your first example should be specified on the metaclass that you're using for your dataclass class. It shouldn't be applied to some ancestor of that metaclass. That means you should apply it to MetaClassChild in your example.

In your second example, you've specified that the default value for init is False, which means that your dataclass has no fields to initialize in the __init__ method. Is that your intent?

[Aran-Fey]

The @dataclass_transform in your first example should be specified on the metaclass that you're using for your dataclass class. It shouldn't be applied to some ancestor of that metaclass.

The PEP says:

If dataclass_transform is applied to a class, dataclass-like semantics will be assumed for any class that directly or indirectly derives from the decorated class or uses the decorated class as a metaclass.

Which is a bit unclear, but to me it does sound like indirectly using the metaclass is fine. Plus, isn't that just... y'know, OOP? If the parent class is a dataclass transform, then so is the child class.

In your second example, you've specified that the default value for init is False, which means that your dataclass has no fields to initialize in the init method. Is that your intent?

It is. I guess that one isn't pyright's fault; I got misled by pyright-play.net. Hovering over the class displays the signature (*args, **kwargs), but reveal_type(Demo.__init__) correctly outputs (self: Demo) -> None.

I've also managed to reproduce one of the other bugs I mentioned, but it appears to have been fixed already. (VScode's pyright version seems to be 2 months out of date...)