Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iterable validataclasses and to_dict() reimplementation #62

Open
binaryDiv opened this issue May 16, 2022 · 0 comments
Open

Iterable validataclasses and to_dict() reimplementation #62

binaryDiv opened this issue May 16, 2022 · 0 comments
Assignees
Labels
breaking changes This issue will cause a breaking change (or deprecation warning). enhancement Improvements to existing features or smaller new features new feature New feature that is not (only) a validator class
Milestone

Comments

@binaryDiv
Copy link
Contributor

As of now, the only way to iterate over a validataclass instance is using the to_dict() method from the ValidataclassMixin or dataclasses.asdict() (which is used internally by the to_dict() method).

There is a lot of problems that bug me about this solution, for example, since to_dict() only uses asdict(), there is no simple way to alter how the dict representation of nested dataclasses looks like (you cannot simply override to_dict() in the inner dataclass, since it's not used by asdict()). Also, to_dict() filters UnsetValue (and optionally None when #39 is implemented) from the dictionary, but only on the top level, not in nested dictionaries.

Because of this, I want to reimplement to_dict() without using asdict(), so that it recursively calls to_dict() for inner dataclasses.

Besides a usable dict representation, I'd also like to make validataclasses themselves iterable, so you can avoid the conversion to a dictionary if you just want to iterate over the fields. It would also be nice to be able to iterate over the field metadata (i.e. iterate over all fields, so you can access field validators, defaults and other metadata).

This issue is a bit more complex and will introduce breaking changes, and I see it as a necessary part of the 1.0.0 update (though it could be released earlier, maybe with some backwards compatibility measurements that will be dropped in 1.0.0).

@binaryDiv binaryDiv added enhancement Improvements to existing features or smaller new features breaking changes This issue will cause a breaking change (or deprecation warning). new feature New feature that is not (only) a validator class labels May 16, 2022
@binaryDiv binaryDiv added this to the 1.0.0 Release milestone May 16, 2022
@binaryDiv binaryDiv self-assigned this May 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking changes This issue will cause a breaking change (or deprecation warning). enhancement Improvements to existing features or smaller new features new feature New feature that is not (only) a validator class
Projects
None yet
Development

No branches or pull requests

1 participant