Implement our own "dataclass" logic

[patrick91]

I think we discussed a few times to remove dataclasses and implement our own solution, this is mostly because:

1. Extending an existing type that has default doesn't work -> https://stackoverflow.com/questions/51575931/class-inheritance-in-python-3-7-dataclasses
2. Dataclasses internals are complicating our code (we have a couple of hacks due do that)
3. Slots are not supported (might be useful for some use cases).

So it might be the case to start thinking about our solution. @jkimbo and I were thinking of vendorizing dataclasses from Python 3.10 (which also supports kwargs only constructors) and then update the implementation from there.

For solving 1 we could use the kwargs only constructor, though this might be a big breaking change. We could also do something smarter that reorders the fields based on if they have default values or not

Worth nothing that we should still be able to support dataclasses.asdict on our types, as people rely on that (we could make our own function and deprecate it, but I wouldn't remove it for the time being).

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[jkimbo]

Would vendoring dataclasses break any editor integration?

[patrick91]

Would vendoring dataclasses break any editor integration?

don’t think so :) for mypy we vendorize the dataclasses plugin already (with our changes) for pyright we are implementing the proposed dataclass transform decorator (which only tells pyright we follow dataclass’ semantics)

for pycharm i’m not sure 🤔

[patrick91]

Going to close this for now, we can always make a new issue if we still think we need to do this :)