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 well-structured and highly readable. It follows Django model conventions with clear separation of concerns. The class is organized logically: fields are grouped together, followed by the manager, constants, Meta class, and methods. Nesting is minimal — the main indentation comes from field definition arguments, which is idiomatic for Django models. Each model field and method has a clear purpose, enhanced by descriptive names and docstrings. The code is concise but not overly compressed; field definitions are multi-line for readability. Action granularity is good, with one logical operation per line. Reading flow is natural, moving from field definitions to class constants to methods. Minor issues include the unused imports at the top (e.g., `Iterable`, `apps`, `ContentType`, `PermissionDenied`, `EmptyManager`) which could be removed, and a slight inconsistency in using string formatting (`"%s %s"`) versus f-strings, but these don't significantly impact readability.
Run 2
The code is highly readable with clear logical organization and consistent formatting. The AbstractUser class is well-structured, with fields, managers, and methods grouped logically. Nesting is minimal, and each model field is clearly separated with descriptive help_text and error_messages. The intent is evident from the class docstring and method names. Code length is appropriate — each field declaration follows Django conventions without unnecessary verbosity. Action granularity is appropriate, with one logical operation per line. Reading flow is natural: imports, class definition, fields in logical order, then methods in order of increasing complexity. Minor deductions: some field definitions could be slightly more compact, and the get_full_name method uses deprecated string formatting, but these don't significantly impact readability.
Run 3
The code is highly readable, with clear imports, logical grouping of fields and methods, and consistent formatting. It uses descriptive names and Django conventions effectively. The ordering of fields is logical, and each field declaration is cleanly separated. Methods are short, focused, and well-documented. Minor readability deductions could be made for the somewhat verbose field declarations and the multiple nested parentheses in those declarations, which slightly interrupt the reading flow. Overall, the structure is flat, intent is clear, and no unnecessary complexity is present.
Run 1
Code Structure: Well organized into imports, model fields, configuration, metadata, and methods. Nesting: Shallow, with indentation mainly for field arguments and the Meta class. Clarity of intent: Descriptive names, docstrings, and help text clearly communicate purpose; however, PermissionsMixin and UserManager are not defined or imported in the snippet. Code length: Appropriately concise for a declarative Django model, though several unused imports add clutter. Action granularity: Statements generally perform one action each, and multiline field declarations make options easy to scan. Reading flow: Natural progression from model definition to utility methods, supported by consistent formatting and spacing.
Run 2
Code Structure: Fields, manager, configuration, metadata, and methods are logically grouped. Nesting: Minimal nesting; multiline field declarations remain easy to follow. Clarity of intent: Descriptive names, docstrings, and field help text clearly explain the model, though PermissionsMixin and UserManager are not defined or imported in the snippet. Code length: Appropriate for a declarative Django model, but numerous unused imports add clutter. Action granularity: Each statement performs a single clear action; multiline declarations improve legibility. Reading flow: The progression from model fields to configuration and behavior is natural and consistent. Overall, highly readable, with minor distractions from imports and unresolved dependencies.
Run 3
Code Structure: Fields, manager, configuration, metadata, and methods are logically grouped. Nesting: Shallow nesting makes the class easy to scan; multiline field definitions remain clear. Clarity of intent: Descriptive names, docstrings, and help text explain the model and its methods well, although PermissionsMixin and UserManager are undefined in the supplied snippet. Code length: Mostly concise, with justified verbosity for field configuration, but several unused imports add clutter. Action granularity: Statements generally perform one action each, with no compressed multi-action lines. Reading flow: The progression from model declarations to behavior is natural and consistent. Minor import clutter and missing dependency definitions prevent a top score.