Source code
from collections.abc import Iterable
from django.apps import apps
from django.contrib import auth
from django.contrib.auth.base_user import AbstractBaseUser, BaseUserManager
from django.contrib.auth.hashers import make_password
from django.contrib.contenttypes.models import ContentType
from django.core.exceptions import PermissionDenied
from django.core.mail import send_mail
from django.db import models
from django.db.models.manager import EmptyManager
from django.utils import timezone
from django.utils.translation import gettext_lazy as _
from .validators import UnicodeUsernameValidator
class AbstractUser(AbstractBaseUser, PermissionsMixin):
"""
An abstract base class implementing a fully featured User model with
admin-compliant permissions.
Username and password are required. Other fields are optional.
"""
username_validator = UnicodeUsernameValidator()
username = models.CharField(
_("username"),
max_length=150,
unique=True,
help_text=_(
"Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only."
),
validators=[username_validator],
error_messages={
"unique": _("A user with that username already exists."),
},
)
first_name = models.CharField(_("first name"), max_length=150, blank=True)
last_name = models.CharField(_("last name"), max_length=150, blank=True)
email = models.EmailField(_("email address"), blank=True)
is_staff = models.BooleanField(
_("staff status"),
default=False,
help_text=_("Designates whether the user can log into this admin site."),
)
is_active = models.BooleanField(
_("active"),
default=True,
help_text=_(
"Designates whether this user should be treated as active. "
"Unselect this instead of deleting accounts."
),
)
date_joined = models.DateTimeField(_("date joined"), default=timezone.now)
objects = UserManager()
EMAIL_FIELD = "email"
USERNAME_FIELD = "username"
REQUIRED_FIELDS = ["email"]
class Meta:
verbose_name = _("user")
verbose_name_plural = _("users")
abstract = True
def clean(self):
super().clean()
self.email = self.__class__.objects.normalize_email(self.email)
def get_full_name(self):
"""
Return the first_name plus the last_name, with a space in between.
"""
full_name = "%s %s" % (self.first_name, self.last_name)
return full_name.strip()
def get_short_name(self):
"""Return the short name for the user."""
return self.first_name
def email_user(self, subject, message, from_email=None, **kwargs):
"""Send an email to this user."""
send_mail(subject, message, from_email, [self.email], **kwargs)
Run 1
The code is clear and well-structured, with a standard Django model layout that separates imports, fields, Meta, and methods. Nesting is minimal, with only one conditional-free method chain. Field definitions are verbose but justified by Django best practices and internationalization. The only readability issues are slight verbosity in field help texts and a minor naming inconsistency (using 'staff status' vs 'active'), but these don't significantly reduce clarity. Overall, it reads naturally and follows established patterns.
Run 2
This Django abstract user model demonstrates excellent readability. The code structure follows Django's conventional model definition pattern, making it immediately recognizable to framework users. Existing imports are organized and mostly used. Nesting is minimal, with fields and methods kept at predictable indentation levels. Each model field is clearly defined with descriptive help_text and validation, showing clear intent. Action granularity is appropriate: each field, method, and Meta option occupies its own line without unnecessary verbosity. Reading flow is natural—imports, class declaration, fields, Meta, methods—mirroring standard Django practices. Minor deductions include some long field definitions that span multiple lines (though this is idiomatic Django) and a few unused imports at the top, which slightly reduces clarity. Overall, this is highly readable, well-structured code that would be easily maintainable by any Django developer.
Run 3
The code is well-structured and highly readable. It follows Django conventions, with clear separation of imports, model fields, Meta options, and methods. The class and method names are descriptive, and docstrings explain their purpose. Field definitions are logically grouped and formatted consistently, with helpful help_text and error_messages for clarity. Nesting is minimal, and each line focuses on a single action or attribute. The use of translation wrappers and validators is standard and does not hinder readability. The only minor drawback is the slightly long import block, but it is organized and justified by the model's dependencies. Overall, this is an exemplary implementation of a Django abstract user model.
Run 1
Code Structure: Fields, manager, configuration, metadata, and methods are logically grouped within a single model class. Nesting: Shallow nesting, limited primarily to field arguments and the Meta class, makes scanning easy. Clarity of intent: Descriptive names, docstrings, and field help text clearly communicate purpose; however, PermissionsMixin and UserManager are undefined in the provided snippet, weakening self-contained clarity. Code length: Appropriately concise for a declarative Django model, though several unused imports add clutter. Action granularity: Statements generally perform one action each, with complex field declarations formatted across readable lines. Reading flow: The progression from model definition to configuration and utility methods is natural and consistent. Minor import cleanup and clearer dependency context would improve readability.
Run 2
Code Structure: Fields, manager, configuration, metadata, and methods are logically grouped. Nesting: Shallow nesting keeps the class easy to scan; multiline field declarations are well formatted. Clarity of intent: Descriptive names, docstrings, and help text clearly explain the user model, although PermissionsMixin and UserManager are not defined or imported in the snippet. Code length: Mostly concise, with useful declarative detail, but several unused imports add clutter. Action granularity: Statements generally perform one action each, and field options appear on separate lines. Reading flow: The progression from model fields to configuration and behavior is natural and consistent with Django conventions.
Run 3
Code Structure: Fields, manager, configuration, metadata, and methods are logically grouped. Nesting: Shallow nesting keeps the class easy to scan; multiline field definitions are clear rather than tangled. Clarity of intent: Descriptive names, docstrings, and field help text explain the model well, though PermissionsMixin and UserManager are not defined or imported in the snippet. Code length: Appropriately concise for a Django model, but several unused imports add clutter. Action granularity: Each statement performs a distinct action, with no compressed multi-action lines. Reading flow: The progression from model fields to configuration and behavior is natural and consistent.