Eric V. Smith <e...@trueblade.com> 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. It could include my add_slots decorator in https://github.com/ericvsmith/dataclasses/blob/master/dataclass_tools.py Such a decorator could then deal with all the complications that I don't want to add to @dataclass. For example, choosing a method name. @dataclass doesn't inject any non-dunder names in the class, but the new decorator could, or it could provide a way to customize the member name. Also, note that your example asdict method doesn't do the same thing as dataclasses.asdict. While you get some speedup by knowing the field names in advance, you also don't do the recursive generation that dataclasses.asdict does. In order to skip the recursive dict generation, you'd either have to test the type of each member (using some heuristic about what doesn't need recursion), or assume the member type matches the type defined in the class. I don't want dataclasses.asdict to make the assumption that the member type matches the declared type. There's nowhere else it does this. I'm not sure how much of the speedup you're seeing is the result of hard-coding the member names, and how much is avoiding recursion. If all of the improvement is by eliminating recursion, then it's not worth doing. I'm not saying the existing dataclasses.asdict can't be sped up: surely it can. But I don't want to remove features or add complexity to do so. ---------- assignee: -> eric.smith _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36662> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
