Sample

pyint-0a511eff9a22-I13

Lower every eligible synchronous for loop to a while loop

Matched original source

Lines235

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2070–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC100Logical lines; fewer is more readable
DeepSeek V4 Pro15.330–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.4430–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=""): 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.9397.215−310.108
Source linesThe number of non-empty source lines.235+94
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.356−6.534

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.236−7.32
Indentation frequencyHow rapidly indentation changes from line to line.210+6.527
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.210−4.398
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.234.909+2.874
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.85.907+0.582
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.062+0.342
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.949−0.018

Intercept 0.07 + feature contributions = -1.341 (log-odds).
Score = sigmoid(-1.341) = 0.207.

Score0.335
Score100
Run 1

The code demonstrates strong readability through clear organization, logical structure, and good use of Django patterns. Imports are organized by module, class methods are well-grouped, and field definitions clearly express intent. Nesting is reasonable, with the deepest branches in `user_change_password` being manageable. Most methods have focused responsibilities and explanatory comments where needed. Action granularity is mostly one-action-per-line, though some complex expressions could benefit from extraction. The main readability challenges are long methods like `user_change_password` with multiple responsibilities and dense conditional logic. Docstrings and comments effectively clarify non-obvious behaviors like the add permission restrictions and form submission validation. Overall, this is production-ready Django admin code that balances completeness with clarity, losing some points for method length and complex control flow in password management.

Run 2

The code is generally readable due to logical structure, clear naming, and separation of concerns. It follows Django admin conventions and uses meaningful method names (e.g., `_add_view`, `user_change_password`). Nesting is reasonable, but the `user_change_password` method is long and contains multiple conditional branches, slightly reducing readability. Action granularity is mostly good, though some blocks combine multiple actions (e.g., validation, message, redirect). The reading flow is natural at the top but becomes denser in larger methods. Concise comments explain non-obvious logic, which helps clarity. Overall, it is well-organized but could benefit from extracting helper methods for the password change flow.

Run 3

The code is generally well-structured with logical grouping of imports, class attributes, and methods. It uses Django's admin conventions effectively. However, readability is reduced by long methods like `user_change_password` and `_add_view`, which contain multiple conditional branches and inline comments that could be extracted into smaller helper methods. The `fieldsets` and `add_fieldsets` definitions are clear but take up many lines. Some complex conditionals like `valid_submission` could benefit from clearer naming or extraction. The code is not deeply nested, but several methods have lengthy bodies. The docstrings and comments are helpful. Overall, the code follows Django patterns, but method length and mixed concerns inside some methods prevent a higher score.

Run 1

Code Structure: Well organized into declarative admin configuration and focused override methods, although user_change_password combines validation, persistence, messaging, redirects, and rendering. Nesting: Most methods are flat with early exits; the POST/form-validation branch introduces moderate nesting. Clarity of intent: Descriptive names, standard Django conventions, and explanatory security comments make the purpose clear, though framework-specific APIs require Django familiarity. Code length: Configuration and context dictionaries justify much of the length, but the password-change method is lengthy and could benefit from helper extraction. Action granularity: Statements generally perform one action per line, with multiline expressions formatted consistently. Reading flow: Configuration precedes behavior, and request handling follows a natural sequence from permission checks to processing and rendering. Long comments and nested redirect construction occasionally interrupt the flow.

Run 2

Code Structure: Configuration is grouped at the class level, and distinct admin behaviors are separated into well-named methods. Nesting: Most methods are shallow and use early exits, but user_change_password contains several nested conditions and a lengthy redirect expression. Clarity of intent: Descriptive names, docstrings, and security-focused comments explain the purpose well; some details require Django familiarity. Code length: Most verbosity comes from necessary configuration and context dictionaries, although the password-change method combines validation, persistence, messaging, redirects, and rendering and could be split into helpers. Action granularity: Statements generally perform one action per line, with readable multiline formatting for complex expressions. Reading flow: Imports, configuration, and methods follow a coherent progression, and the request handling flows naturally from checks through processing to rendering. Deep formatting and framework-specific conventions occasionally interrupt scanning.

Run 3

Code Structure: Configuration is grouped at the class level, and methods separate form selection, permissions, URL routing, and response handling logically. Nesting: Most methods are shallow, but user_change_password contains several nested branches and a lengthy redirect expression. Clarity of intent: Descriptive names, standard Django conventions, and comments explaining security and workflow decisions make the purpose clear; framework knowledge is still needed. Code length: Most verbosity comes from necessary configuration and context dictionaries, although the password-change method is long and could be split into helpers. Action granularity: Statements generally perform one action per line, with consistent formatting for multiline expressions. Reading flow: Imports, configuration, and methods form a coherent progression, and early returns simplify several paths. The combination of validation, persistence, messaging, redirects, and template setup in one method slightly interrupts the otherwise natural flow.