Sample

pyint-561b224b7b45-I05

Rewrite eligible decimal integer literals in hexadecimal notation

Matched original source

Lines235

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2110–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC100Logical lines; fewer is more readable
DeepSeek V4 Pro16.330–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.4280–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"] = 0x1 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.357−6.536

Intercept 8.87 + feature contributions = -213.774 (log-odds).
Score = sigmoid(-213.774) = 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.209−4.375
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.953−0.018

Intercept 0.07 + feature contributions = -1.318 (log-odds).
Score = sigmoid(-1.318) = 0.211.

Score0.335
Score100
Run 1

The code is highly readable Django admin customization, scoring 17/20. Strengths: excellent modular organization with clear method separation and logical grouping; flat nesting in most methods; comprehensive docstrings and comments explaining non-obvious logic; concise, well-named helper methods (e.g., _add_view, lookup_allowed); single-action-per-line throughout; natural reading flow from decorators through method bodies. Minor deductions: user_change_password is somewhat long (~75 lines) with moderate nesting (if/else followed by nested if/elif), requiring careful reading to trace all branches; the response_add method mutates request.POST with magic-seeming behavior (request.POST['_continue'] = 0x1) though well-commented; get_urls uses starred expansion slightly reducing immediate readability. The use of ternary expressions and string formatting is clean, and template/field configurations are declarative and scannable. Overall, professional-grade code with minor complexity in the password-change view that could benefit from extraction into smaller helper methods.

Run 2

This is highly readable Django admin code. Code structure is logical, with clear separation of concerns: form configuration, permission checks, and view handling. Nesting is moderate but well-controlled; the user_change_password method has deeper nesting but remains comprehensible. Intent is explicit through descriptive method names and helpful comments explaining non-obvious decisions like the add-permission check. Code length is appropriate - verbose in places but not unnecessarily so, with detailed error messages being justified. Action granularity is mostly one action per line, though some lines combine operations. Reading flow is natural, following Django admin conventions that experienced developers will recognize. Minor deductions: the user_change_password method is somewhat long, and there's slight complexity in the response_add method's POST manipulation. Overall, this is production-quality code that balances Django framework requirements with clear, maintainable implementation.

Run 3

The code is generally well-structured and follows Django admin conventions, with clear separation of concerns and descriptive comments. Imports are organized, and class attributes are grouped logically. However, readability is reduced by a few deeply nested blocks in `user_change_password`, which contains a lengthy POST-handling section with multiple conditions. While most methods are concise and single-purpose, `_add_view` has a long docstring-like comment that could be simplified. The use of tuple/list unpacking and string formatting is standard but slightly dense in places. Overall, the code is readable for experienced Django developers but would benefit from flattening the password-change logic and reducing comment verbosity.

Run 1

Code Structure: Configuration and behavior are logically grouped within UserAdmin, with focused overrides; user_change_password handles several responsibilities and could be split. Nesting: Most methods are flat or use early exits, but POST validation and password updates introduce moderate nesting. Clarity of intent: Descriptive names, familiar Django conventions, and security-focused comments explain the purpose well; framework internals require Django knowledge, and 0x1 is less intuitive than 1. Code length: Most verbosity comes from necessary configuration and context dictionaries, although the password-change method and some comments are lengthy. Action granularity: Statements generally perform one action per line, with complex expressions formatted across lines. Reading flow: Configuration precedes methods, and request handling follows a natural progression from permission checks through validation, updates, and rendering. Dense context construction and nested redirect formatting slightly interrupt the flow.

Run 2

Code Structure: Configuration and behavior are clearly separated within a cohesive admin class, with focused methods for distinct workflows. Nesting: Most methods are shallow and use early returns; the password-change handler has moderately nested validation and response logic. Clarity of intent: Descriptive names, explicit configuration, and useful security comments explain purpose well, though Django-specific conventions require framework knowledge. Code length: Most verbosity is justified by configuration and context construction, but the lengthy password-change method and some comments increase reading effort. Action granularity: Statements generally perform one action each, and complex expressions are formatted across lines without combining unrelated operations. Reading flow: Imports, configuration, hooks, validation, persistence, and rendering follow a natural sequence. The main readability limitation is the password-change method combining several responsibilities, alongside visually dense nested configuration structures.

Run 3

Code Structure: Configuration is grouped clearly, and focused methods separate admin customization, permissions, and form handling. The password-change method combines several responsibilities and could be split further. Nesting: Most methods are shallow with early exits, but POST validation and password updates introduce moderate nesting. Clarity of intent: Descriptive names, familiar Django conventions, and comments explain security checks and unusual workflows; framework knowledge is needed for some context keys and overrides. Code length: Most length comes from necessary configuration and explicit context construction, though the password-change method and some comments are lengthy. Action granularity: Statements generally perform one action per line, with readable multiline expressions. Reading flow: Methods follow a coherent configuration-to-request-handling progression, and the password workflow proceeds logically from authorization through validation, saving, and rendering. Deeply formatted redirect construction and the unexplained 0x1 slightly interrupt readability.