Cerberus 2: Proposal for stricter and more flexible type checks at the same time!

[funkyfuture]

i propose to make the type checking mechanics simpler and more flexible regarding the possible constraints with the next major release of Cerberus.

this means that users need to refactor their custom validators - remove any method prefixed with _validate_type_ - resp. the employed schemas when upgrading. uses with the vanilla validator may require schema changes due to slight semantical shifts. type checks can no longer be misused for what rules and validators are supposed for.

users could publish enhanced sets of type definitions, e.g. for uses with NumPy or other common frameworks that define data types.

an implementation would roughly look like this (in the style proposed in #372):

class Validator(metaclass=ValidatorMeta):
    type_definitions = {
        'binary':
            TypeDefinition('binary', (collections.abc.ByteString), ()),
        'boolean':
            TypeDefinition('boolean', (bool,), ()),
        'bytearray':  # new to enhance builtins coverage
            TypeDefinition('bytearray', (bytearray,), ()),
        'bytes':  # new to enhance builtins coverage
            TypeDefinition('bytes', (bytes,), ()),
        'complex':  # new to enhance builtins coverage
            TypeDefinition('complex', (complex,), ()),
        'date':
            TypeDefinition('date', (datetime.date,), ()),
        'datetime':
            TypeDefinition('datetime', (datetime.datetime,), ()),
        'dict':  # this is stricter again, but unambigious
            TypeDefinition('dict', (dict,), ()),
        'float':  # stricter, but unambigious
            TypeDefinition('float', (float,), ()),
        'frozenset':  # new to enhance builtins coverage
            TypeDefinition('frozenset', (frozenset,), ()),
        'integer':
            TypeDefinition('integer', (int,), ()),
        'list':  # this is stricter again, but unambigious
            TypeDefinition('list', (list,), ()),
        'mapping':  # new
            TypeDefinition('mapping', (collections.abc.Mapping,), ()),
        'none':   # does this obsolete the 'null' rule?
            TypeDefinition('none', (type(None),), ()),
        'number':
            TypeDefinition('number', (int, float), (bool,)),
        'sequence':  # new; should AnyStr and ByteString be excluded?
            TypeDefinition('sequence', (collections.abc.Sequence), ()),
        'set':
            TypeDefinition('set', (set,), ()),
        'string':  # this includes bytes again
            TypeDefinition('string', (typing.AnyStr,), ()),
        'tuple':  # new to enhance builtins coverage
            TypeDefinition('tuple', (tuple,), ()),
        'unicode':  # new
            TypeDefinition('string', (str,), ()),
    }
    # an alias
    type_definitions['null'] = type_definitions['none']


@validation_rule(name='type')
def type_check(validator, constraint, value):
    if not _validate_type(validator, constraint, value):
        validator.error(…)


def _validate_type(validator, constraint, value) -> bool:
    if isinstance(constraint, str):
        # the known string constraints are needed for serialized schemas
        return _validate_type(
            validator, validator.type_definitions[constraint], value
        )

    elif isinstance(constraint, (list, tuple)):
        # the container type for multiple allowed types is restricted to list
        # and tuple, hence classes from collections.abc can be used in the
        # fallback check; both can be checked with default string constraints
        return any(_validate_type(validator, x, value) for x in constraint)

    elif isinstance(constraint, TypeDefinition):
        return isinstance(value, definition.included_types) \
            and not isinstance(value, definition.excluded_types)

    # the last two possible checks are great for simple drop-ins, ide/editor
    # fancyness and dynamic uses
    elif isinstance(constraint, typing.TypeVar):
        # some fiddling with the constraint's __bound__ and __constraints__
        pass

    # as a fallback
    try:
        return isinstance(value, constraint)
    except Exception as e:
        raise RuntimeError('Invalid constraint for type rule.') from e

should more types from collections.abc be included in the vanilla validator's type_definitions? my guess is that these would rather be used in situations where schema serialization plays no role.

should range and memoryview also be included in the vanilla type defintions to fully cover builtin types? i'd consider these as data that is hardly exchanged between components, well actually hardly as data at all.

[funkyfuture]

implemented in

• e19fcc3
• 1162e46
• bf67dd9
• 37dd532
• ef09ff9