Using classes as `dataclass_transform` `field_specifiers`

Typing
1

According to dataclass_transform decorator specification, the field_specifiers argument takes a static tuple of functions or classes. The current specification explicitly mentions classes on multiple occasions:

field_specifiers specifies a static list of supported classes that describe fields. Some libraries also supply functions to allocate instances of field specifiers, and those functions may also be specified in this tuple.

The standard dataclass behavior supports only one type of field specifier called Field plus a helper function (field) that instantiates this class, so if we were describing the stdlib dataclass behavior, we would provide the tuple argument (dataclasses.Field, dataclasses.field).

Field specifier classes are allowed to use other parameters in their constructors …

However, on this recently created pyright issue, @erictraut seemed to indicate that classes are not and will not be supported, either in pyright or elsewhere.

That’s confusing to me, given the explicitness of the specification. However, it appears @erictraut is both the author and implementer of the spec, so it seems he speaks with some authority here.

I created this issue to request confirmation of that decision. Moreover, if that decision is final, then at the very least it seems the specification and documentation ought to be updated accordingly.

Edit: Is this the right forum for this discussion? Or should I have opened an issue on the Typing Council’s issue tracker? I learned of its existence just now.

2 Likes
2

Opening an issue here first is good. If the discussion leads to a proposed change to the typing spec, then opening an issue for the Typing Council to look at is one of the next steps. But it’s good to first have an informal discussion to try to hash out what if any change is needed.

1 Like