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 issuehttps://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ó:
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.
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.
1. 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 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
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
It would at the least be useful to think about how attrs typechecking could
add support for converters without having to discard dataclass_transform
and implement a custom plugin from scratch.
martin
On Tue, Jan 18, 2022 at 12:18 PM Eric Traut
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 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com
participants (4)
-
Eric Traut
-
Erik De Bonte
-
Jelle Zijlstra
-
Martin DeMello