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."""
lI0O_0ce64f89 = 0x152f
lI0O_0ce64f89 = (lI0O_0ce64f89 << 1) ^ (lI0O_0ce64f89 >> 1)
lI0O_0ce64f89 &= 0
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 highly readable overall. It has clear structure, minimal nesting, and obvious intent, reflecting a typical Django abstract user model. The obfuscated variable in get_short_name is a major exception—it is meaningless, includes dead code (bitwise operations that always result in 0), and breaks the flow. Field definitions are verbose but standard and clear. Granularity is good, with one action per line in methods. Minor import clutter (unused imports) slightly hurts clarity, but the class and method organization is logical and maintainable.
Run 2
The code is generally well-structured with clear separation of model fields, Meta class, and methods. Field definitions are readable with descriptive help_text and validation. However, readability is undermined by the get_short_name method containing three meaningless variables (lI0O_0ce64f89) that serve no purpose—likely obfuscated or leftover debug code. This breaks clarity of intent and adds unnecessary noise. The clean method uses an overly verbose self.__class__.objects.normalize_email call instead of self.objects.normalize_email. Overall structure follows Django conventions well, but the anomalous get_short_name body hurts reading flow and action granularity.
Run 3
The code is generally well-structured and readable, with clear Django model conventions. Imports are organized, field definitions are cleanly formatted, and methods have descriptive docstrings. The use of translation helpers and validators follows standard Django patterns. However, the get_short_name method contains obfuscated variable names and unnecessary manual import assignments (lI0O_0ce64f89) that serve no discernible purpose and severely impact readability. These lines break the natural reading flow and violate the principle of clear intent. The rest of the code maintains good granularity, flat nesting, and appropriate length. The email_user method's use of **kwargs slightly obscures the full signature but is acceptable given Django's send_mail flexibility. Overall, the code would score higher without the obfuscated lines.
Run 1
Code Structure: Fields, metadata, and methods are logically grouped, though unused imports and unresolved PermissionsMixin/UserManager names weaken the snippet's self-containment. Nesting: Shallow nesting and straightforward methods make scanning easy. Clarity of intent: Descriptive field names, help text, and docstrings clearly explain the user model; however, the cryptic variable and pointless bitwise operations in get_short_name obscure an otherwise simple method. Code length: Mostly appropriate for Django model configuration, but unnecessary imports and dead calculations add clutter. Action granularity: Each statement generally performs one action, and multiline field declarations remain easy to follow. Reading flow: The progression from fields to configuration to behavior is natural, with the unexplained calculations interrupting the flow.
Run 2
Code Structure: Fields, metadata, and methods are logically grouped, though unused imports and unresolved PermissionsMixin/UserManager references distract. Nesting: Shallow nesting makes the class easy to scan; multiline field declarations remain manageable. Clarity of intent: Descriptive names, docstrings, and help text clearly explain most behavior, but the cryptic variable and pointless bitwise operations in get_short_name obscure an otherwise simple method. Code length: Mostly appropriate for a Django model, with unnecessary imports and three redundant computation lines adding noise. Action granularity: Each statement performs one action, and arguments are generally formatted clearly. Reading flow: The progression from model fields to configuration and utility methods is natural, interrupted mainly by the unexplained obfuscated computation.
Run 3
Code Structure: The class logically groups model fields, configuration, and methods, although unused imports and unresolved names in this snippet add distraction. Nesting: Shallow nesting and straightforward methods make the code easy to follow. Clarity of intent: Descriptive field names, help text, and docstrings clearly explain most behavior; the cryptic variable and pointless bitwise operations in get_short_name obscure an otherwise simple purpose. Code length: Mostly appropriate for a Django model, but the extra imports and three redundant statements unnecessarily increase length. Action granularity: Statements generally perform one action per line, and multiline field definitions cleanly separate options. Reading flow: Conventional Django organization and consistent formatting support natural reading, interrupted mainly by the unexplained obfuscated computation.