
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:
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 inhttps://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! _______________________________________________ Typing-sig mailing list --typing-sig@python.org To unsubscribe send an email totyping-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address:eric@trueblade.com