#26790: Move BaseUserManager.normalize_email() to AbstractUser
-------------------------------------+-------------------------------------
Reporter: Huynh Thanh Tam | Owner: Jacob
Type: | Walls
Cleanup/optimization | Status: closed
Component: contrib.auth | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: normalize_email | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Carlton Gibson):
* status: assigned => closed
* resolution: => needsinfo
* stage: Accepted => Unreviewed
Comment:
OK, so Mariusz and I have each come back the PR and the discussion here a
number of times over the last few months.
Having conferred we're of the opinion that the proposed change is not
worth the disruption: there's clearly confusion is the code as to the
levels the attributes and the methods that call them live at but,
ultimately the situation isn't much improved after the patch is applied.
There isn't consensus as to which level we should move the methods to (if
at all): `AbstractBaseUser`, `AbstractUser`, or leave them on
`BaseUserManager`.
(On this last — it's in `create()` that you want `normalize_email()` so we
go from `self.<...>` to `AbstractBaseUser.<...>` in the
[https://github.com/django/django/pull/13527/files#diff-
b37e77411714dcbb9a65b45e4aa5e64167560461808805328f40deb86f92407cR1042
MyUserManager example in the diff] — and I, for one, start wondering if
we've really made an improvement... — this is just illustrative — let's
not get distracted by it please.)
The various comments comment:2 comment:4 comment:5 comment:9, plus then
Adam's reply on the mailing list point to different possible ways we could
cut this cake. If I **had to** choose I'd probably go with Tim's
suggestion to move the logic to `AbstractUser` — but I just don't think
it's worth the disruption — and I'm equally drawn to "These methods belong
on Manager"…
There's a cluster of code which is more coupled than we'd like. OK. I'm
all for clean code, but I'm not sure we have a plan to make it better.
(Again, having conferred with Mariusz and having looked at it for some
time.) At that point we think the API stability policy dominates. We don't
think we should change it without a better analysis. (The current
situation is not the end of the world...)
So... I'm going to close this as `needsinfo`. If someone wants to puzzle
this out such that we have an API that's clearly cleaner, plus a nice
deprecation path for folks that have implemented on the current situation,
and we can get a consensus together on the DevelopersMailingList then,
we're very happy to reopen and push forwards. Otherwise, for the moment at
least, I think there are probably higher ROI areas we can work on.
I hope that makes sense to all.
--
Ticket URL: <https://code.djangoproject.com/ticket/26790#comment:11>
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 on the web visit
https://groups.google.com/d/msgid/django-updates/065.3ec3a783a1f54e02e30fa1374c2a026c%40djangoproject.com.
