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 close(self):
super().clean()
self.email = self.__class__.objects.normalize_email(self.email)
def updateAccount(self):
"""
Return the first_name plus the last_name, with a space in between.
"""
reference = "%s %s" % (self.first_name, self.last_name)
return reference.strip()
def validateBuffer(self):
"""Return the short name for the user."""
return self.first_name
def createUser(self, history, nextKey, recentPath=None, **config):
"""Send an email to this user."""
send_mail(history, nextKey, recentPath, [self.email], **config)
Run 1
The code begins well with clear imports and a structured model definition, following Django conventions. However, readability drops significantly in the latter half. Method names like close(), updateAccount(), validateBuffer(), and createUser() are misleading: their names do not match their actual behavior (e.g., close() cleans and normalizes email, updateAccount() returns a full name). This creates ambiguous intent. Parameter names like 'history', 'nextKey', and 'config' obscure meaning. The single-purpose principle is violated, and reading flow is disorganized due to mismatched names and functionality. While the model fields are well-formatted and the class docstring is helpful, the confusing methods and inconsistent naming reduce overall clarity. The code is not deeply nested and length is moderate, but logical organization suffers because related functionality is mislabeled.
Run 2
The code has a clear initial structure with well-formatted model fields, but becomes confusing after the Meta class. Several methods have misleading names and unclear purposes: 'close()' calls clean and normalizes email, 'updateAccount()' returns a full name string, 'validateBuffer()' returns a first name, and 'createUser()' sends an email. The parameter names in createUser (history, nextKey, recentPath, config) are ambiguous and do not match their actual use in send_mail. This creates significant ambiguity about intent. While the code layout is flat and generally well-indented, the mismatch between method names and their behavior makes it difficult to understand what the class is supposed to do beyond the admin-compliant user model. Some method docstrings appear copied from other functionality and do not describe the actual operations. Overall, the class reads as if it has been auto-generated or refactored poorly, undermining clarity and maintainability.
Run 3
The code has significant readability issues despite organized imports and field definitions. The methods at the bottom have misleading names that don't reflect their actual behavior: 'close' calls clean and normalizes email, 'updateAccount' returns the full name, 'validateBuffer' returns the first name, and 'createUser' sends an email. Method parameters use vague names like 'history', 'nextKey', and 'recentPath' that don't correspond to their email purpose (subject, message, from_email). The docstrings contradict the method bodies—'updateAccount' says it returns first_name plus last_name, which matches its logic, but the method name suggests updating an account. The class structure is reasonable with clear Django model field definitions, but the method naming and parameter choices make the code's intent ambiguous and confusing to read. The code appears to be intentionally obfuscated or poorly refactored, severely impacting clarity of intent and reading flow.
Run 1
Code Structure: Fields, model configuration, and methods are logically grouped, although numerous unused imports and undefined PermissionsMixin/UserManager references distract. Nesting: Minimal nesting; multiline field declarations remain easy to follow. Clarity of intent: Field names and help text are clear, but method names are misleading: close cleans data, updateAccount returns a full name, validateBuffer returns a first name, and createUser sends email. Generic email parameter names further obscure intent. Code length: Mostly appropriate for a declarative Django model, with avoidable import clutter. Action granularity: Statements generally perform one action per line, and field options are clearly separated. Reading flow: The progression from fields to metadata to methods is natural, but inconsistent camelCase naming and contradictions between method names and docstrings interrupt comprehension.
Run 2
Code Structure: Fields, configuration, metadata, and methods are logically grouped, but unused imports and undefined PermissionsMixin and UserManager weaken self-containment. Nesting: Shallow nesting and simple methods make the code easy to scan. Clarity of intent: Field names, help text, and docstrings are clear, but method names such as close, updateAccount, validateBuffer, and createUser misleadingly describe cleaning, name retrieval, and email sending; email parameters are similarly obscure. Code length: Mostly concise, with justified multiline field declarations, though unnecessary imports add clutter. Action granularity: Each statement performs a distinct action, with no compressed multi-statement lines. Reading flow: The model follows a natural Django layout, but inconsistent camelCase naming and mismatches between method names and behavior interrupt comprehension.
Run 3
Code Structure: Fields, configuration, metadata, and methods are logically grouped, but unused imports and undefined PermissionsMixin and UserManager weaken self-contained readability. Nesting: Shallow nesting and simple method bodies make the code easy to scan. Clarity of intent: Field names and help text are clear, but method names are misleading: close cleans data, updateAccount returns a full name, validateBuffer returns a first name, and createUser sends email. Generic email parameters further obscure intent, despite helpful docstrings. Code length: Mostly concise; multiline field declarations are justified, while unused imports add clutter. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: The declarative model layout flows naturally, but inconsistent camelCase method naming and mismatches between names and behavior interrupt comprehension.