Changing defaults of dataclass_transform()

[Bluenix2]

I am backporting the slots creating from Python 3.10 to older versions and want to use dataclass_transform() to help type checkers understand me inserting slots. The issue is that it doesn't appear that Pyright is honouring the defaults (which differ from dataclasses in that it is True).

In the following example, I switched to init because it is easier to showcase:

from typing import Callable, TypeVar

from typing_extensions import dataclass_transform


ClsT = TypeVar('ClsT')


@dataclass_transform()
def add_init(init: bool = False) -> Callable[[ClsT], ClsT]:
    def inner(cls: ClsT) -> ClsT:
        if init:
            return _add_init(cls)  # Pretend this was defined
        else:
            return cls
    return inner


@add_init()
class ABC:
    a: int


ABC()  # Argument missing for parameter "a"

I'd expect the code to pass, as I want Pyright to follow my defaults (no __init__() defined).

Released on 22/03/2019, 04:10:23
Last updated 14/05/2022, 21:36:36
Identifier ms-pyright.pyright

[erictraut]

The dataclass_transform mechanism is not designed to pick up non-default behaviors from the signature of a function that it is applied to. Such behaviors must be specified as arguments to the dataclass_transform call.

dataclass_transform provides a way to override some behaviors. In particular, you can override the default setting for eq, order, and kw_only. It doesn't currently allow you to override the behavior of init. It could be extended to provide this, but the initial version doesn't provide such support. To do so, we'd need to add a new keyword argument to dataclass_transform called init_default: bool = .... This sounds to me like a reasonable and natural extension, but it would have to go through a standards process — at a minimum, a discussion in the typing-sig, and possibly a follow-on PEP.

In any case, pyright is working as intended for the code above.

[Bluenix2]

Doesn't Pyright read the signature of the decorated function (being called) when deciding whether the default is overriden?

[erictraut]

No, that's not how dataclass_transform works.

Keep in mind that dataclass_transform is designed to accommodate both decorator functions and metaclasses. Both techniques are used by various dataclass-like libraries. In the case of metaclasses, there would be no way to understand the default behaviors without specifying them as arguments to the dataclass_transform call. For that reason, we decided to codify that approach for dataclass_transform.

Please refer to PEP 681 for details.