default emil to null instead of empty string in `normalize_email`

[amirreza8002]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

hi
so as you know normalize_email converts falsy emails into an empty string

this is documented and i did this pr on it.

but even now, i do think it'd be much better if it just used None

one example of this causing problem, is when you have unique=True,
as you know, empty strings are counted when you have unique=True, so if one used doesn't provide an email, all other users are forced to provide one, unless we change how users are made manually

Problem

it'd be good to allow unique values by default

Request or proposal

request

Additional Details

No response

Implementation Suggestions

No response

[github-actions]

Thank you amirreza8002 for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[carltongibson]

We hit a similar constraint on django-unique-user-email. Essentially you make email required, since adding the unique constraint means empty strings can't stand for the null value.

(The alternative is to make the field nullable... — or whatever. It's a kind of edge-case because no-one is really using django-unique-user-email if they want users without emails but, still...)

Details lacking:

I assume you're talking about custom user models? What's the workaround you're using already? Is that painful?

What's the BC implications of changing this? How can they be mitigated?

[amirreza8002]

It's a kind of edge-case because no-one is really using django-unique-user-email if they want users without emails but,

i see many projects that have email as optional, but still enforce uniqueness, in fact, most projects i see are like this

What's the workaround you're using already?

iirc django-allauth doesn't use create_user, and thus normalize is not called

it is anoying that you can't even do default=None, since normalize_email still turns it into empty string

What's the BC implications of changing this?

well i'm not sure, i personally don't see how something would be depending on email to be defaulted to "", but there is always someone doing things i can't see :p

but if someone is depending on "" as default, well they can just have that as default by default="" , which is easy to do.
in contrast, if you want null, you have to go in and overwrite normalize_email, which arguably needs more effort

[shangxiao]

Folks, please remember to add the "current solution or workaround" to the problem in your proposal 👍…

My 2¢: I don't think the new-issues should turn "Django doesn't do this out of the box" complaint fest. Proposal should include solutions so that the community can identify those without a solution as they'd be the more important ones to be discussing.

One solution is to use a partial index:

class User(AbstractUser):
    ...

    class Meta:
        constraints = [
            UniqueConstraint(
                fields=["email"],
                condition=~Q(email=""),
                name="unique_email",
            )
        ]

Another is to override normalize_email() and customise its behaviour to suite your needs.