Sample

pyint-923035fd1ea3-SRC

Unmodified source class

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 Pro17.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 excellent structure and readability despite its complexity. It is organized logically with clear sections and well-named methods. Nesting is reasonable, with only 2-3 levels deep in more complex areas. Intent is clarified through docstrings and explanatory comments, particularly in the _add_view and user_change_password methods. The code follows Django admin conventions, making it familiar to experienced Django developers. While somewhat lengthy due to inherent complexity of User admin functionality, it maintains concise well-focused methods. Action granularity is appropriate with one operation per line. The reading flow is natural, progressing through permissions checks, form processing, and response generation. Minor improvements could include extracting the password change context dictionary into a helper method for more modular organization.

Run 2

The code demonstrates strong readability through clear structure and logical organization. It follows Django admin conventions consistently, making it immediately recognizable to experienced Django developers. The class is well-organized with attributes grouped logically, methods following a clear flow, and decorators applied appropriately. Nesting is generally shallow, though the user_change_password method has some depth with nested conditionals. The code's intent is clear throughout - each method has a focused purpose, and comments explain non-obvious business logic (like the permission check in _add_view). Code length is appropriate for the complexity - while user_change_password is long, it handles a complex workflow without unnecessary verbosity. Action granularity is mostly good, with one primary action per line, though some lines combine multiple operations. Reading flow is natural and follows Django admin patterns. Minor deductions for the long user_change_password method which could potentially be refactored into smaller helper methods, and for some dense multi-purpose lines in the form handling logic.

Run 3

This Django admin class demonstrates strong readability through its well-organized structure and clear separation of concerns. The code benefits from Django's inherent patterns, using declarative attributes like `fieldsets`, `list_display`, and `search_fields` that make configuration explicit. Methods are purposefully named and logically grouped, with each serving distinct responsibilities. Nesting levels remain manageable - even the most complex method (`user_change_password`) follows a linear flow rather than deep nesting. Comments are sparse but effective, explaining non-obvious business logic like permission checks. The method `_add_view` is cleanly extracted to separate transaction handling from logic. Each action occupies its own line, with appropriate line breaks for readability. The code maintains a natural reading flow from imports through configuration to methods. Minor deductions for the long `user_change_password` method (which handles multiple concerns including form processing, validation, and context building) and some multi-line string concatenations that could be sectioned further. Overall, this is exemplary Django admin code that balances framework conventions with understandable organization.

Run 1

Code Structure: Well organized into a Django admin class, with declarative configuration followed by focused lifecycle methods; user_change_password combines several responsibilities. Nesting: Most methods are flat and use early returns, but password submission handling has moderately deep conditional nesting. Clarity of intent: Descriptive method and variable names, explanatory comments, and explicit permission checks make purpose clear, though Django conventions require framework familiarity. Code length: Mostly justified by configuration and workflow requirements, but the password-change method and some comments are lengthy. Action granularity: Statements generally perform one action per line, and multiline expressions are consistently formatted. Reading flow: Configuration, validation, updates, redirects, and rendering follow a natural progression; nested URL construction and the large context dictionary slightly interrupt the flow.

Run 2

Code Structure: Configuration is grouped at the top, and focused methods separate form selection, permissions, routing, and responses. The password-change method combines several responsibilities. Nesting: Most methods are shallow and use early returns, but POST validation and redirect construction introduce deeper nesting. Clarity of intent: Descriptive names, standard Django conventions, and explanatory security comments make the purpose clear, although framework-specific behavior requires Django knowledge. Code length: Most verbosity comes from necessary configuration, context dictionaries, and helpful comments; the password-change method is comparatively long. Action granularity: Statements generally perform one action per line, with complex expressions formatted across multiple lines. Reading flow: Imports, configuration, and related methods follow a coherent sequence, and the password workflow proceeds naturally from authorization through validation, persistence, feedback, and rendering.

Run 3

Code Structure: Configuration is grouped clearly, and distinct admin behaviors are separated into focused methods; user_change_password handles several responsibilities and could be decomposed. Nesting: Most methods are shallow and use early exits, but POST processing contains multiple nested conditions and a visually deep redirect expression. Clarity of intent: Descriptive names, explanatory security comments, and familiar Django conventions make the purpose clear, though framework knowledge is required. Code length: Most length comes from necessary configuration and context dictionaries; the password-change handler and some comments are lengthy. Action granularity: Statements generally perform one action per line, with multiline expressions formatted consistently. Reading flow: The progression from configuration through form selection, permissions, request handling, and responses is logical; nested submission handling slightly interrupts the otherwise natural flow.