Proposal: Support for dataclasses (PEP-557)

Use-case abstract

Validate instances of dataclasses with Cerberus.

---

Proposal

@rhettinger concluded his talk at PyCon about dataclasses with the outlook that third-party-libraries would take the task to validate these. inevitably i thought about enabling Cerberus to do so.

hence i propose to add a module cerberus.dataclasses that would provide the following features:

• a Validator class that extends cerberus.validator.Validator
  • takes dataclass instances as input beside mappings
  • derives a schema from:
    • a field’s type annotation (*)
    • a field’s default or default_factory setting implemented by a dataclass
    • rules that are provided as a field’s metadata['cerberus'] value
  • validates against a mapping representation of a dataclass against that
  • fields with dataclass instances as value are handled accordingly (nesting)
• a validate function
  • follows the paradigm of the stdlib’s dataclasses module
  • a customized validator can be provided as keyword argument
  • it should be capable to return the used validator for error inspection (, when a keyword argument is given or by default?)
• as i assume there’ll be no way to not support normalization, the functions normalized and validated as well

*: as type information are provided as annotations in a dataclass’ metadata, Cerberus’ lack of capability to validate against such constraints is a showstopper for this feature.

while this feature could be postponed to a post-2.0-release, the outlook on this feature is rather increasing my drive to get started with the 2.x branch at all.

reminder: there’s a backport for Python 3.6.

[nicolaiarocci]

Let’s do this.

[funkyfuture]

thank you very much. this is a good impulse to figure out design details. i want to point that i only have brief practical expierence with the dataclasses module. some thoughts about your gist:

1. i see that the docs hardly the introspective properties of dataclasses. the __dataclass_fields__ property should be used to as sole source to derive from.

2. i’d really prefer to use a field’s type property as constraint for the type rule in the derived schema. that way the code is short, abstract and it can handle any input.

3. what about typing.Union and typing.Optional?

4. at least these rules should be dropped if present in a provided rules set and a critical warning be emitted: required, default, default_setter. oh, that should be implemented with a proper schema that validates that a validator is about to use. i’m too tited for details, that stuff lives in cerberus.schema. it’s kinda messy to get into it; that refactor for Python 3 is more convenient to read to get a general idea. maybe the dataclass validator could specify a schema for these rules that unconditionally raises an exception in a check_with handler as rules can’t be removed with a subclass so far (with a stacked metaclass?!)

have a good night.