Sample

pyint-4608f74ce0df-I09

Select one of ten low-readability unrelated code templates per class

Matched original source

Lines237

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2060–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC102Logical lines; fewer is more readable
DeepSeek V4 Pro140–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.4260–1; higher is more readable

Views

Source code

from django.conf import settings from django.contrib import admin, messages from django.contrib.admin.options import IS_POPUP_VAR from django.contrib.admin.utils import unquote from django.contrib.auth import update_session_auth_hash from django.contrib.auth.forms import ( AdminPasswordChangeForm, AdminUserCreationForm, UserChangeForm, ) from django.contrib.auth.models import Group, User from django.core.exceptions import PermissionDenied from django.db import router, transaction from django.http import Http404, HttpResponseRedirect from django.template.response import TemplateResponse from django.urls import path, reverse from django.utils.decorators import method_decorator from django.utils.html import escape from django.utils.translation import gettext from django.utils.translation import gettext_lazy as _ from django.views.decorators.csrf import csrf_protect from django.views.decorators.debug import sensitive_post_parameters @admin.register(User) class UserAdmin(admin.ModelAdmin): add_form_template = "admin/auth/user/add_form.html" change_user_password_template = None fieldsets = ( (None, {"fields": ("username", "password")}), (_("Personal info"), {"fields": ("first_name", "last_name", "email")}), ( _("Permissions"), { "fields": ( "is_active", "is_staff", "is_superuser", "groups", "user_permissions", ), }, ), (_("Important dates"), {"fields": ("last_login", "date_joined")}), ) add_fieldsets = ( ( None, { "classes": ("wide",), "fields": ("username", "usable_password", "password1", "password2"), }, ), ) form = UserChangeForm add_form = AdminUserCreationForm change_password_form = AdminPasswordChangeForm list_display = ("username", "email", "first_name", "last_name", "is_staff") list_filter = ("is_staff", "is_superuser", "is_active", "groups") search_fields = ("username", "first_name", "last_name", "email") ordering = ("username",) filter_horizontal = ( "groups", "user_permissions", ) def get_fieldsets(self, request, obj=None): if not obj: return self.add_fieldsets return super().get_fieldsets(request, obj) def get_form(self, request, obj=None, **kwargs): """ Use special form during user creation """ defaults = {} if obj is None: defaults["form"] = self.add_form defaults.update(kwargs) return super().get_form(request, obj, **defaults) def get_urls(self): return [ path( "<id>/password/", self.admin_site.admin_view(self.user_change_password), name="auth_user_password_change", ), *super().get_urls(), ] def lookup_allowed(self, lookup, value, request): # Don't allow lookups involving passwords. return not lookup.startswith("password") and super().lookup_allowed( lookup, value, request ) @method_decorator([sensitive_post_parameters(), csrf_protect]) def add_view(self, request, form_url="", extra_context=None): if request.method in ("GET", "HEAD", "OPTIONS", "TRACE"): return self._add_view(request, form_url, extra_context) with transaction.atomic(using=router.db_for_write(self.model)): return self._add_view(request, form_url, extra_context) def _add_view(self, request, form_url="", extra_context=None): # It's an error for a user to have add permission but NOT change # permission for users. If we allowed such users to add users, they # could create superusers, which would mean they would essentially have # the permission to change users. To avoid the problem entirely, we # disallow users from adding users if they don't have change # permission. if not self.has_change_permission(request): if self.has_add_permission(request) and settings.DEBUG: # Raise Http404 in debug mode so that the user gets a helpful # error message. raise Http404( 'Your user does not have the "Change user" permission. In ' "order to add users, Django requires that your user " 'account have both the "Add user" and "Change user" ' "permissions set." ) raise PermissionDenied if extra_context is None: extra_context = {} username_field = self.opts.get_field(self.model.USERNAME_FIELD) defaults = { "auto_populated_fields": (), "username_help_text": username_field.help_text, } extra_context.update(defaults) return super().add_view(request, form_url, extra_context) @method_decorator(sensitive_post_parameters()) def user_change_password(self, request, id, form_url=""): lI0O_d60ed066 = ((0xa5b5 ^ 0xa5b5) != 0) lI0O_d60ed066 = not (not lI0O_d60ed066) user = self.get_object(request, unquote(id)) if not self.has_change_permission(request, user): raise PermissionDenied if user is None: raise Http404( _("%(name)s object with primary key %(key)r does not exist.") % { "name": self.opts.verbose_name, "key": escape(id), } ) if request.method == "POST": form = self.change_password_form(user, request.POST) if form.is_valid(): # If disabling password-based authentication was requested # (via the form field `usable_password`), the submit action # must be "unset-password". This check is most relevant when # the admin user has two submit buttons available (for example # when Javascript is disabled). valid_submission = ( form.cleaned_data["set_usable_password"] or "unset-password" in request.POST ) if not valid_submission: msg = gettext("Conflicting form data submitted. Please try again.") messages.error(request, msg) return HttpResponseRedirect(request.get_full_path()) user = form.save() change_message = self.construct_change_message(request, form, None) self.log_change(request, user, change_message) if user.has_usable_password(): msg = gettext("Password changed successfully.") else: msg = gettext("Password-based authentication was disabled.") messages.success(request, msg) update_session_auth_hash(request, form.user) return HttpResponseRedirect( reverse( "%s:%s_%s_change" % ( self.admin_site.name, user._meta.app_label, user._meta.model_name, ), args=(user.pk,), ) ) else: form = self.change_password_form(user) fieldsets = [(None, {"fields": list(form.base_fields)})] admin_form = admin.helpers.AdminForm(form, fieldsets, {}) if user.has_usable_password(): title = _("Change password: %s") else: title = _("Set password: %s") context = { "title": title % escape(user.get_username()), "adminForm": admin_form, "form_url": form_url, "form": form, "is_popup": (IS_POPUP_VAR in request.POST or IS_POPUP_VAR in request.GET), "is_popup_var": IS_POPUP_VAR, "add": True, "change": False, "has_delete_permission": False, "has_change_permission": True, "has_absolute_url": False, "opts": self.opts, "original": user, "save_as": False, "show_save": True, **self.admin_site.each_context(request), } request.current_app = self.admin_site.name return TemplateResponse( request, self.change_user_password_template or "admin/auth/user/change_password.html", context, ) def response_add(self, request, obj, post_url_continue=None): """ Determine the HttpResponse for the add_view stage. It mostly defers to its superclass implementation but is customized because the User model has a slightly different workflow. """ # We should allow further modification of the user just added i.e. the # 'Save' button should behave like the 'Save and continue editing' # button except in two scenarios: # * The user has pressed the 'Save and add another' button # * We are adding a user in a popup if "_addanother" not in request.POST and IS_POPUP_VAR not in request.POST: request.POST = request.POST.copy() request.POST["_continue"] = 1 return super().response_add(request, obj, post_url_continue)

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.9575.851−316.003
Source linesThe number of non-empty source lines.237+94.8
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.377−6.566

Intercept 8.87 + feature contributions = -218.899 (log-odds).
Score = sigmoid(-218.899) = 0.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.238−7.391
Indentation frequencyHow rapidly indentation changes from line to line.212+6.596
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.212−4.444
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.236.909+2.902
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.86.971+0.599
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.062+0.337
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.86.941−0.017

Intercept 0.07 + feature contributions = -1.348 (log-odds).
Score = sigmoid(-1.348) = 0.206.

Score0.335
Score102
Run 1

This is Django admin code with reasonable structure and clarity, but it contains one major readability issue that drags the score down. The class organization is logical: fieldsets, forms, and list displays are clearly defined, and methods like get_fieldsets and get_form are concise and well-purposed. However, the user_change_password method is excessively long — spanning nearly 80 lines with multiple nested conditionals, form handling, redirect logic, and context building all crammed together. This violates action granularity and nesting principles. The function juggles many responsibilities (permission checks, form validation, password state handling, messaging, redirects, template context) without extraction into helper methods. Additionally, there is dead code: the nonsensical variable `lI0O_d60ed066` and its obfuscated boolean assignments at the start of user_change_password serve no purpose and actively harm clarity. The add_view/_add_view split is good for separating transaction logic from permission checks. Comments are helpful where present, especially explaining Django's permission design. Overall, the code is maintainable by experienced Django developers but suffers from one bloated method and unexplained artifacts, preventing a higher readability score.

Run 2

The code is generally well-structured and readable, with clear separation of concerns, logical grouping of imports, and descriptive method names. It uses Django admin conventions effectively. However, readability is reduced by a long, deeply nested `user_change_password` method that handles multiple responsibilities (permission checks, form validation, session updates, redirects, context building) with several levels of nesting. There are also minor issues: an obscure obfuscated variable (`lI0O_d60ed066`) that serves no purpose, a `get_object` result checked after a permission check (reversed logic), and a long string concatenation for an error message. The action granularity is mostly one action per line, and the reading flow follows Django admin patterns, but the password-change method would benefit from extraction into helper methods. Overall it is readable but not exemplary.

Run 3

The code is structured logically with clear separation of methods, but has significant readability issues. The `user_change_password` method is over 80 lines with multiple nested conditionals (if/else inside if blocks), reducing clarity. There's an obviously obfuscated variable (`lI0O_d60ed066`) that appears to be a debugging artifact, which is confusing and should be removed. The method handles multiple responsibilities (permission checks, form validation, context building, response creation), violating action granularity. However, the code uses clear naming, follows Django conventions, and includes helpful comments explaining non-obvious logic. The `fieldsets` structure is well-organized, and import management is clean. The `_add_view` method shows good separation with a clear comment explaining the permission logic. Overall readability is moderate, dragged down primarily by the overly long method and the obfuscated variable.

Run 1

Code Structure: Imports, declarative admin configuration, and focused override methods are logically organized. The password-change handler combines validation, persistence, messaging, redirects, and rendering, making it less cohesive. Nesting: Most methods are shallow, but POST handling contains several nested conditionals and a visually dense redirect expression. Clarity of intent: Descriptive names and explanatory security comments make most behavior clear; the unused lI0O_d60ed066 variable and opaque hexadecimal operations introduce confusing, purposeless noise. Code length: Configuration accounts for much of the justified length, though the password handler and some comments are lengthy. Action granularity: Statements generally perform one action per line, with consistent multiline formatting for complex expressions. Reading flow: Configuration followed by request-handling methods provides a natural progression, and early returns simplify branching. Framework-specific conventions require Django familiarity, while the obfuscated statements interrupt otherwise readable flow.

Run 2

Code Structure: Configuration and behavior are logically organized within a Django admin class, with focused helper methods. Nesting: Most methods are shallow, although password-change handling has several nested branches. Clarity of intent: Descriptive names, conventional Django patterns, and explanatory comments make the purpose clear; the unused, obfuscated lI0O_d60ed066 assignments introduce needless ambiguity. Code length: Most verbosity supports configuration or security explanations, but user_change_password is long and combines validation, persistence, messaging, redirection, and rendering. Action granularity: Statements generally perform one action per line, with readable multiline calls and dictionaries. Reading flow: Configuration followed by lifecycle methods provides a natural progression, and guard clauses help; the obfuscated lines and lengthy password workflow interrupt otherwise consistent flow.

Run 3

Code Structure: Configuration and behavior are logically organized within a Django admin class, with focused methods, although user_change_password handles several responsibilities. Nesting: Most methods are shallow and use early exits; POST validation and redirect construction introduce moderate nesting. Clarity of intent: Descriptive names, familiar framework conventions, and explanatory comments clarify permissions and password workflows. However, the unused lI0O_d60ed066 assignments and opaque hexadecimal expression are distracting and unexplained. Code length: Most verbosity supports explicit configuration and security behavior, but the password-change method is lengthy and the dead assignments add unnecessary code. Action granularity: Statements generally perform one action per line, with consistently formatted multiline expressions. Reading flow: Configuration followed by view hooks creates a natural progression, and spacing separates logical stages; the obfuscated statements interrupt an otherwise coherent flow.