RFC: Improved API for registering field validator methods

Status quo

Validator methods are registered by decorating them with @validates('my_field_name').

from marshmallow import fields, Schema, ValidationError, validates

class ItemSchema(Schema):
    quantity = fields.Int()

    @validates('quantity')
    def validate_quantity(self, value):
        if value > 30:
            raise ValidationError('Quantity must not be greater than 30')

Proposed API

Validator methods are registered by decorating them with @my_field.validator.

from marshmallow import fields, Schema, ValidationError

class ItemSchema(Schema):
    quantity = fields.Int()

    @quantity.validator
    def validate_quantity(self, value):
        if value > 30:
            raise ValidationError('Quantity must not be greater than 30')

Benefits

• Less prone to user error (no magic strings).
• Removes redundant code. Since Field#validator() decorator would just append to a field’s validators attribute, there would be no need for this code.
• Better introspection of fields. Again, since Field#validator() appends to Field#validators, code that introspects fields (e.g. apispec) can find all of a field’s validators in one place.

[immerrr]

Less magic strings is good, so it seems a nice idea to replace @validates('quantity') with @validates(quantity).

I would however like to point out that schema-level validators may check how two or more fields interact with each other. A recently introduced feature allows skipping schema-level validation if the validation of the field itself failed, it can be generalized to multiple fields, too. There’s not much sense in checking how two, say, integer parameters interact with each other if one of those is unexpectedly a dictionary. Current API could support that naturally with @validates([quantity, quality, speed]), but it is not that obvious to me how to do that with the proposed one.

[sloria]

Discussed offline: it’s not clear that the OP was a good idea. This API gets confusing when fields are inherited. validates('string') looks magic on the surface, but at least it’s clear what its behavior is.

Closing this for now.