PEP for dataclass_transform support for converter field descriptor parameter
![](https://secure.gravatar.com/avatar/87388c2faa3c4d423c5dd9e436028e4f.jpg?s=120&d=mm&r=g)
Howdy y'all! Picking up on PEP 681, and more specifically this post: https://mail.python.org/archives/list/typing-sig@python.org/thread/5XZQK7GVI... I'm interested to hear thoughts on how a PEP to add this functionality would be received. My usage doesn't come from attrs (but shares the problem-space) in that our library defines dataclasses that clients instantiate (which all happen to be frozen and only contain immutable types). Currently to be type-compliant without mypy plugins, we have to define __init__ and do the conversion inside it. Example: @dataclass(frozen=True) class MyData: values: tuple[int, ...] number_map: FrozenOrderedDict[str, int] # a frozen dict, essentially def __init__(self, values: Iterable[int], number_map: Mapping[str, int]): ... However this has a few drawbacks: - Extremely verbose: certainly not as ideal as `values: tuple[int, ...] = my_field(..., converter=tuple)` without the init method - Prone to overload explosion: dicts have an overloaded init with 2 unary-constructors. To be most correct, we'd need to overload our init with each possible cross-product of value unary constructors I think this is in the spirit of attrs' converter field, and I don't feel like forcing our clients to convert is really in the spirit of Python. Additionally, I agree with Jelle Zijlstra in https://mail.python.org/archives/list/typing-sig@python.org/message/7SDEVKQH... that support for this should used typed-converters (instead of using Any, as suggested elsewhere). So far, I can think of a few complexities to document, but otherwise would love to hear if this feature is prohibitively difficult or just doesn't fit. Challenges: - Overloaded converters (such as dict's __init__): Would need to overload the dataclass __init__, and generate a cross-product of overloads if multiple converters - Converters accepting varargs: The type-checker needs to treat the callable's possible first arg as the lone arg (and not error on variable arg functions, again consider dict's constructor) - Generic converters (such as the value `tuple`): There's no great way for Python users pre Py 3.9 to use built-in generics as converters, however users could roll their own converter easily. In Py 3.9+, `tuple[int]` should work at type-checking-time and at runtime. (Whether it would work "out of the box" at type-check-time is up for debate) Thanks for your time and thoughts!
![](https://secure.gravatar.com/avatar/2828041405aa313004b6549acf918228.jpg?s=120&d=mm&r=g)
I'll take Jelle's word for it that type checkers can figure out the types involved. I left this out of dataclasses originally because of the desire to get something simple into the stdlib. But maybe now is the time to add it. My concerns at the time were: * People will want something more complicated, like converts that either act on multiple fields, or set multiple fields from a single input value. * Converters and validators seem at least a little related, and I didn't want to do both until we'd figured out how (or if) they're related. * Impact on type checkers. The second one might not actually be a concern, but I recall at the time it was on my mind. Maybe attrs has done enough to pave the way for dataclasses to now adopt converters. It would be useful to do some research on how attrs works with converters, and also to see if they have any misgivings for design decisions they've made. Eric On 12/27/2022 10:07 AM, joshdcannon@gmail.com wrote:
![](https://secure.gravatar.com/avatar/3247bfd67c8fa4c4a08b8d30e49eab39.jpg?s=120&d=mm&r=g)
If there is an appetite to incorporate converters into the stdlib dataclass, I think that's the preferable route. The dataclass_transform mechanism is meant to automatically incorporate any new facilities incorporated into stdlib dataclass, so a PEP that extends dataclass will also extend dataclass_transform. -- Eric Traut Contributor to Pyright & Pylance Microsoft
![](https://secure.gravatar.com/avatar/2828041405aa313004b6549acf918228.jpg?s=120&d=mm&r=g)
I'll take Jelle's word for it that type checkers can figure out the types involved. I left this out of dataclasses originally because of the desire to get something simple into the stdlib. But maybe now is the time to add it. My concerns at the time were: * People will want something more complicated, like converts that either act on multiple fields, or set multiple fields from a single input value. * Converters and validators seem at least a little related, and I didn't want to do both until we'd figured out how (or if) they're related. * Impact on type checkers. The second one might not actually be a concern, but I recall at the time it was on my mind. Maybe attrs has done enough to pave the way for dataclasses to now adopt converters. It would be useful to do some research on how attrs works with converters, and also to see if they have any misgivings for design decisions they've made. Eric On 12/27/2022 10:07 AM, joshdcannon@gmail.com wrote:
![](https://secure.gravatar.com/avatar/3247bfd67c8fa4c4a08b8d30e49eab39.jpg?s=120&d=mm&r=g)
If there is an appetite to incorporate converters into the stdlib dataclass, I think that's the preferable route. The dataclass_transform mechanism is meant to automatically incorporate any new facilities incorporated into stdlib dataclass, so a PEP that extends dataclass will also extend dataclass_transform. -- Eric Traut Contributor to Pyright & Pylance Microsoft
participants (3)
-
Eric Traut
-
Eric V. Smith
-
joshdcannon@gmail.com