Documentation example has wrong number of arguments in validation method

[rgerkin]

In cerberus 1.2, the example for http://docs.python-cerberus.org/en/stable/customize.html#custom-validators seems to have the wrong number of arguments. I was only able to get this to work with 2 arguments (including self), not 3. For example:

import quantities as pq
from cerberus import Validator

class MyValidator(Validator):  
    def _validate_type_seconds(self, value):
        if not isinstance(value, pq.quantity.Quantity):
            self._error('%s' % value, "Must be a Python quantity")
        if not value.simplified.units == pq.s:
            self._error('%s' % value, "Must have units of seconds")
        return True
        
schema = {'amount': {'type': 'seconds'}}
v = MyValidator(schema)
assert v.validate({'amount': 10*pq.s}) is True
assert v.validate({'amount': 10*pq.mV}) is False

Note that def _validate_type_seconds(self, value) has only self and value, whereas the documentation example has self, field, and value.

[funkyfuture]

had you confused custom validators with type checks? because the example you show is about a deprecated form of type checks, while you link the section about custom validators.

[rgerkin]

@funkyfuture OK I see that in ce1ef4f you removed the kind of type check that I am currently using. However, I'm not sure how to implement it using the more restrictive type checking you have now. The isinstance part is easy, and appears to be what cerberus.TypeDefinition basically does. But I also need to make more fine-grained checks (see the if not value.simplified.units == pq.s in my code sample above). Can this be done with Custom Validators? Expanding the documentation for Custom Validators with a functional example (as you have for e.g. Custom Coercers) would be helpful.

[funkyfuture]

certainly, different approaches are possible with Cerberus (a custom rule or check_with would be involved in any way, i guess). i would suggest to separate testing different aspects of a field with the designated rules and additional tests on each aspect. in your case, test the type with a TypeDefinition and add a custom rule to test the units attribute. this leaves the most leverage when composing and extending schemas.

shall we leave this issue open regarding an improvement of the docs? the briefly discussed paradigm isn't covered there yet and i recently noticed that it could use some polishing (reviewing @nir0s claim that the docs on customization were execellent, thank you for the 🌷)

[rgerkin]

Thanks, yes, a good working example would be helpful, essentially showing how you would replace the lost deprecated custom types functionality. No rush, but sometime before the release that removes custom types would be great!

[funkyfuture]

the lost deprecated custom types functionality

i'd rather describe it as the "possibility to over-use the type-role which was propagated for too long". i'm noting this as i'd prefer examples that focus on good practices rather than on a deficitary view on "losses". while the latter is good to unlearn things, i'd say it's additional, confusing information for new users in the long term. of course we can still amend the UPGRADING.rst to serve the former.