Improving consistency between field validators and password validators

[Antoliny0919]

@ryanhiebert

Given my concerns about password validators that require a user to process not raising errors (by design), my suggestion is to add a __call__ method only to the password validators that do not need the user to be passed in. I’d think that there shouldn’t be any optional arguments to the __call__ method when implemented to conform to the normal protocol for validators.

I agree with this opinion as well.

I think all password validators, except for UserAttributeSimilarityValidator, can be used as general purpose validators.
In particular, MinimumLengthValidator is functionally identical to MinLengthValidator and MaxLengthValidator in the standard validators (it’s closer to a customized version of MinLengthValidator for passwords).
Also, I believe that NumericPasswordValidator can be effectively used in scenarios beyond just password validation.

I consider my skills to be lacking and think Django’s password validation logic is excellently and beautifully designed. However, I struggle to understand the decision to design password validation using AUTH_PASSWORD_VALIDATORS in settings.py. I believe this could have been sufficiently handled using general Field and Validator functionality.
Of course, compared to the developers of Django, my perspective might seem like that of a beginner, which could explain my impression.