George Sakkis <[email protected]> added the comment:
> I think the best thing to do is write another decorator that adds this
> method. I've often thought that having a dataclasses_tools third-party module
> would be a good idea.
I'd be happy with a separate decorator in the standard library for adding these
methods. Not so sure about a third-party module, the added value is probably
not high enough to justify an extra dependency (assuming one is aware it exists
in the first place).
> or assume the member type matches the type defined in the class.
This doesn't seem an unreasonable assumption to me. If I'm using a dataclass, I
probably care enough about its member types to bother declaring them and I
wouldn't mind if a particular method expects that the members actually match
the types. This behaviour would be clearly documented.
Alternatively, if we go with a separate decorator, whether this assumption
holds could be a parameter, something like:
def add_asdict(cls, name='asdict', strict=True)
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue36662>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
