dataclass_transform support for converter field descriptor parameter

Thanks to everyone that has provided feedback on the dataclass_transform PEP so far! There's one open issue<https://github.com/debonte/peps/blob/dataclass_transforms/pep-9999.rst#conve...> right now, and I wondered if anyone had feedback specifically on it: converter field descriptor parameter The attrs library supports a converter field descriptor parameter, which is passed a callable that is called by the generated __init__ method to convert the supplied value to some other desired value. This is tricky to support since the parameter type in the synthesized __init__ method needs to accept uncovered values, but the resulting field is typed according to the output of the converter. There may be no good way to support this because there's not enough information to derive the type of the input parameter. We currently have two ideas: 1. Add support for a converter field descriptor parameter but then use the Any type for the corresponding parameter in the __init__ method. 2. Say that converters are unsupported and recommend that attrs users avoid them. Some aspects of this issue are discussed on the pyright GitHub site. [https://github.com/microsoft/pyright/discussions/1782?sort=old#discussioncom...] Thanks, Erik

El mar, 18 ene 2022 a las 11:42, Erik De Bonte via Typing-sig (< typing-sig@python.org>) escribió:
I'm not sure why we'd need Any. If I understand correctly, a converter is basically a callable (T1) -> T2, that makes it so that for a field of type T2, the constructor accepts arguments of type T1. So if we see something like `attr: int = field(converter=len)`, the type checker has enough information to create an `__init__` with type `attr: Sized`. That said, I don't have a strong opinion on whether this should be included in the proposal. I can see how this feature can be useful, but it does increase complexity.

Converters are specific to `attrs`, so I don't think the idea belongs in a standard like this. IMO, the bar is incredibly high for supporting a library-specific feature like this especially when it adds complexity. If support for converters is added to the stdlib `dataclass` in a future Python release, then it would make sense to extend `dataclass_transform` to include it at that time. It's worth noting that `dataclass` has a common history with `attrs`, and when `dataclass` was standardized as part of PEP 557, converters didn't make the cut. That would seem to imply that converters were not that important. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

El mar, 18 ene 2022 a las 11:42, Erik De Bonte via Typing-sig (< typing-sig@python.org>) escribió:
I'm not sure why we'd need Any. If I understand correctly, a converter is basically a callable (T1) -> T2, that makes it so that for a field of type T2, the constructor accepts arguments of type T1. So if we see something like `attr: int = field(converter=len)`, the type checker has enough information to create an `__init__` with type `attr: Sized`. That said, I don't have a strong opinion on whether this should be included in the proposal. I can see how this feature can be useful, but it does increase complexity.

Converters are specific to `attrs`, so I don't think the idea belongs in a standard like this. IMO, the bar is incredibly high for supporting a library-specific feature like this especially when it adds complexity. If support for converters is added to the stdlib `dataclass` in a future Python release, then it would make sense to extend `dataclass_transform` to include it at that time. It's worth noting that `dataclass` has a common history with `attrs`, and when `dataclass` was standardized as part of PEP 557, converters didn't make the cut. That would seem to imply that converters were not that important. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft
participants (4)
-
Eric Traut
-
Erik De Bonte
-
Jelle Zijlstra
-
Martin DeMello