-
Notifications
You must be signed in to change notification settings - Fork 2
Iterable validataclasses and to_dict() reimplementation #62
Copy link
Copy link
Open
Labels
breaking changesThis issue will cause a breaking change (or deprecation warning).This issue will cause a breaking change (or deprecation warning).enhancementImprovements to existing features or smaller new featuresImprovements to existing features or smaller new featuresnew featureNew feature that is not (only) a validator classNew feature that is not (only) a validator class
Milestone
Metadata
Metadata
Assignees
Labels
breaking changesThis issue will cause a breaking change (or deprecation warning).This issue will cause a breaking change (or deprecation warning).enhancementImprovements to existing features or smaller new featuresImprovements to existing features or smaller new featuresnew featureNew feature that is not (only) a validator classNew feature that is not (only) a validator class
Type
Fields
Give feedbackNo fields configured for issues without a type.
As of now, the only way to iterate over a validataclass instance is using the
to_dict()method from theValidataclassMixinordataclasses.asdict()(which is used internally by theto_dict()method).There is a lot of problems that bug me about this solution, for example, since
to_dict()only usesasdict(), there is no simple way to alter how the dict representation of nested dataclasses looks like (you cannot simply overrideto_dict()in the inner dataclass, since it's not used byasdict()). Also,to_dict()filtersUnsetValue(and optionallyNonewhen #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 usingasdict(), so that it recursively callsto_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).