#36809: Allow EmailValidator to return 'domain_part' in ValidationError params
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: Daniel E
Type: | Onetti
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):
* has_patch: 0 => 1
* keywords: => EmailValidator
* needs_better_patch: 0 => 1
* needs_docs: 0 => 1
* needs_tests: 0 => 1
* owner: Kundan Yadav => Daniel E Onetti
* stage: Unreviewed => Accepted
* type: Uncategorized => Cleanup/optimization
Comment:
Hello Daniel! Thanks for the report, for taking the time to prepare a
patch, and for following the contributing guide. I appreciate that.
I agree that the use case is valid and that being able to reference the
domain in error messages can be genuinely useful. That said, I am not
convinced that simply adding `domain_part` to `ValidationError.params` is
the best fit for Django core. It solves the immediate problem, but does so
in a way that feels quite specific rather than structural. It also risks
committing to an API that only partially reflects how `EmailValidator`
actually works.
Looking at the other validators in this module, there is a clear pattern
of separating parsing, normalization, and validation into distinct steps
or methods, even when the final error surface remains simple.
`EmailValidator` is somewhat inconsistent here: it already decomposes the
value into user and domain components, but does so inline inside
`__call__`, with no clear extension points. Adding a single extra param
addresses the symptom rather than the structure.
I think a more Django aligned approach would be to re-evaluate
`EmailValidator` as a whole and give it clearer, overridable validation
hooks, while keeping full backward compatibility. For example, introducing
explicit methods like `validate_recipient()` and `validate_domain()`,
called from `__call__`, would allow customization via subclassing without
re-parsing the email or wrapping errors. The existing
`validate_domain_part()` could be kept for compatibility and potentially
deprecated later, since it currently returns a boolean.
So in short, I agree with the motivation, but I think the solution needs
to be broader and more structural than the current proposal in order to
align better with Django's existing validator patterns.
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019b36c6a4f4-5a49e0a1-a49f-467b-b8e2-d84ca1aeeccd-000000%40eu-central-1.amazonses.com.
