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 a(self):
super().clean()
self.email = self.__class__.objects.normalize_email(self.email)
def b(self):
"""
Return the first_name plus the last_name, with a space in between.
"""
e = "%s %s" % (self.first_name, self.last_name)
return e.strip()
def c(self):
"""Return the short name for the user."""
return self.first_name
def d(self, f, g, h=None, **i):
"""Send an email to this user."""
send_mail(f, g, h, [self.email], **i)
Run 1
The code shows severe readability issues. The method names 'a', 'b', 'c', and 'd' completely obscure their purposes, making the code impossible to understand without deep investigation. The parameter 'e' is used for what clearly should be 'full_name', 'f' should be 'subject', 'g' should be 'message', etc. The obfuscated naming destroys clarity of intent and reading flow. While the Django model field definitions themselves follow reasonable patterns with good formatting, the methods that follow negate this benefit. The code also appears incomplete - the UserManager is referenced but not defined, and PermissionsMixin is used without import. The action granularity is acceptable but the semantic emptiness of variable names makes the code almost unreadable. This appears to be deliberately obfuscated Django code where meaningful names have been replaced with single letters, reducing readability to near zero despite maintaining syntactically valid structure.
Run 2
The code has a clear logical structure with fields, manager, and settings separated, and model field definitions are well-formatted with good line breaking and descriptive help text. However, readability suffers from poor method naming: methods a(), b(), c(), and d() are meaningless and obscure their purpose. Method b() uses a single-letter variable name 'e' for full_name, and method d() uses 'f', 'g', 'h', 'i' for subject, message, from_email, and kwargs, which makes the code hard to understand without reading the method body. The class is well-documented but lacks a docstring for a(), and the naming choices violate Python PEP-8 best practices. Additionally, the imports include several unused modules (apps, auth, ContentType, PermissionDenied, EmptyManager), adding noise. The model attributes and Meta class are well-structured and maintain appropriate nesting, but the method names and parameters severely reduce clarity.
Run 3
The code has reasonable structure and imports, but intentional obfuscation of method names (a(), b(), c(), d()) destroys clarity of intent. Method parameters (f, g, h, i) are meaningless, making the email-sending method's purpose impossible to understand without deep inspection. The unused imports (auth, apps, ContentType, PermissionDenied, EmptyManager) add noise. While the model fields are well-organized and Django conventions are followed, the critical failure is that the public API communicates nothing about what these methods do. The get_full_name method renamed to b() loses all semantic value. Action granularity is acceptable, but reading flow collapses when encountering cryptic single-letter method names. This code appears deliberately sabotaged through renaming, dropping an otherwise well-structured Django model from readable to nearly incomprehensible. A reader would need to reverse-engineer each method's implementation to understand what it does.
Run 1
Code Structure: Fields, configuration, metadata, and methods are logically grouped, but numerous unused imports and undefined references to PermissionsMixin and UserManager reduce self-contained clarity. Nesting: Shallow nesting makes the class easy to scan. Clarity of intent: Descriptive field names, help text, and docstrings communicate the model’s purpose, but method names a–d and variables e–i obscure behavior and parameter meanings. Code length: Mostly concise; multiline field declarations are justified by their configuration, while unused imports add clutter. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: The progression from fields to metadata to behavior is natural, although cryptic method names interrupt understanding and force readers to inspect implementations.
Run 2
Code Structure: Fields, configuration, metadata, and methods are logically grouped, although unused imports and undefined PermissionsMixin and UserManager weaken self-contained readability. Nesting: Shallow nesting and short methods make the code easy to scan. Clarity of intent: Descriptive field names, help text, and docstrings explain the model well, but methods a–d and variables e–i obscure behavior and parameter meanings. Code length: Mostly concise; multiline field declarations are justified by their configuration, while unnecessary imports add clutter. Action granularity: Each statement performs a single clear action, without compressed or compound lines. Reading flow: The progression from fields to metadata to behavior is natural, but cryptic method names interrupt comprehension and require readers to inspect implementations.
Run 3
Code Structure: Fields, configuration, metadata, and methods are logically grouped, although several unused imports and undefined references to PermissionsMixin and UserManager distract. Nesting: Shallow nesting makes the code easy to scan; multiline field declarations remain manageable. Clarity of intent: Descriptive field names, help text, and docstrings explain the model well, but method names a–d and parameter/local names e–i obscure behavior and API meaning. Code length: Mostly appropriate for a Django model, with some unnecessary import clutter. Action granularity: Statements generally perform one action per line, and method bodies are small. Reading flow: The progression from fields to metadata to methods is natural, but cryptic method names interrupt understanding and force readers to inspect implementations or docstrings.