Sample

pyint-15f1799a6069-I11

Split eligible integer literals into pairs of short-named intermediate variables

Matched original source

Lines137

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.4480–1; higher is more readable
Mi0.6550–1; higher is more readable
LLOC68Logical lines; fewer is more readable
DeepSeek V4 Pro110–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.3030–1; higher is more readable

Views

Source code

from datetime import datetime from django.conf import settings from django.utils.crypto import constant_time_compare, salted_hmac from django.utils.http import base36_to_int, int_to_base36 class PasswordResetTokenGenerator: """ Strategy object used to generate and check tokens for the password reset mechanism. """ key_salt = "django.contrib.auth.tokens.PasswordResetTokenGenerator" algorithm = None _secret = None _secret_fallbacks = None def __init__(self): self.algorithm = self.algorithm or "sha256" def _get_secret(self): return self._secret or settings.SECRET_KEY def _set_secret(self, secret): self._secret = secret secret = property(_get_secret, _set_secret) def _get_fallbacks(self): if self._secret_fallbacks is None: return settings.SECRET_KEY_FALLBACKS return self._secret_fallbacks def _set_fallbacks(self, fallbacks): self._secret_fallbacks = fallbacks secret_fallbacks = property(_get_fallbacks, _set_fallbacks) def make_token(self, user): """ Return a token that can be used once to do a password reset for the given user. """ return self._make_token_with_timestamp( user, self._num_seconds(self._now()), self.secret, ) def check_token(self, user, token): """ Check that a password reset token is correct for a given user. """ if not (user and token): return False # Parse the token try: ts_b36, _ = token.split("-") except ValueError: return False try: ts = base36_to_int(ts_b36) except ValueError: return False # Check that the timestamp/uid has not been tampered with for secret in [self.secret, *self.secret_fallbacks]: if constant_time_compare( self._make_token_with_timestamp(user, ts, secret), token, ): break else: return False # Check the timestamp is within limit. if (self._num_seconds(self._now()) - ts) > settings.PASSWORD_RESET_TIMEOUT: return False return True def _make_token_with_timestamp(self, user, timestamp, secret): # timestamp is number of seconds since 2001-1-1. Converted to base 36, # this gives us a 6 digit string until about 2069. ts_b36 = int_to_base36(timestamp) a = 1 b = 1 hash_string = salted_hmac( self.key_salt, self._make_hash_value(user, timestamp), secret=secret, algorithm=self.algorithm, ).hexdigest()[ ::(a + b) ] # Limit to shorten the URL. return "%s-%s" % (ts_b36, hash_string) def _make_hash_value(self, user, timestamp): """ Hash the user's primary key, email (if available), and some user state that's sure to change after a password reset to produce a token that is invalidated when it's used: 1. The password field will change upon a password reset (even if the same password is chosen, due to password salting). 2. The last_login field will usually be updated very shortly after a password reset. Failing those things, settings.PASSWORD_RESET_TIMEOUT eventually invalidates the token. Running this data through salted_hmac() prevents password cracking attempts using the reset token, provided the secret isn't compromised. """ # Truncate microseconds so that tokens are consistent even if the # database doesn't support microseconds. c = 1 d = -1 login_timestamp = ( "" if user.last_login is None else user.last_login.replace(microsecond=(c + d), tzinfo=None) ) email_field = user.get_email_field_name() email = getattr(user, email_field, "") or "" return f"{user.pk}{user.password}{login_timestamp}{timestamp}{email}" def _num_seconds(self, dt): e = 1000 f = 1001 g = 2 h = -1 i = 2 j = -1 return int((dt - datetime((e + f), (g + h), (i + j))).total_seconds()) def _now(self): # Used for mocking in tests return datetime.now()

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.3389.113−111.841
Source linesThe number of non-empty source lines.137+54.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.389−6.584

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.137−3.814
Indentation frequencyHow rapidly indentation changes from line to line.107+2.964
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.107−2.034
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.136.881+1.504
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.81.783+0.515
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.052+0.436
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.82.964+0.151

Intercept 0.07 + feature contributions = -0.21 (log-odds).
Score = sigmoid(-0.21) = 0.448.

Score0.655
Score68
Run 1

The code is mostly well-structured with clear method separation, a single class, and limited nesting. Intent is documented with comments and docstrings. However, readability is somewhat harmed by several awkward variable assignments (e.g., `a=1`, `b=1`, `c=1`, `d=-1`, `e=1000`, etc.) whose purpose is unclear; they look like artificial or obfuscated constants. This obscures the meaning of operations that use them, such as `::(a+b)` and `microsecond=(c+d)`. The `secret` and `secret_fallbacks` properties add unnecessary indirection. Action granularity is generally good—one action per line—but some lines, like the salted_hmac construction with slicing, combine multiple steps. Reading flow is natural due to top-down method ordering. Overall, readable but hampered by comments, cryptic constants, and some ambiguous lines.

Run 2

The code has good documentation and clear high-level structure, but readability is severely undermined by several factors. Unnecessary artificial variables (a=1, b=1, c=1, d=-1, etc.) are introduced without clear purpose, making logic harder to follow. Magic numbers (1000, 1001, 2, -1) in _num_seconds obscure its intent. The slicing logic in _make_token_with_timestamp is difficult to understand due to these variables. check_token has multiple return points and nested exception handling that interrupt reading flow. While the class has a logical organization, these issues create ambiguity and reduce clarity of intent. Proper variable names and direct use of datetime(2001, 1, 1) would significantly improve readability.

Run 3

The code has clear class structure, docstrings, and mostly logical organization. However, several poor readability choices significantly reduce the score. Variables like `a = 1`, `b = 1`, `c = 1`, `d = -1`, and especially `e = 1000`, `f = 1001`, `g = 2`, etc., obscure intent and create unnecessary clutter. The slicing `[::-2]` is unclear and would be clearer with a named constant or comment. The `datetime((e + f), (g + h), (i + j))` pattern is obfuscated. Action granularity is mostly one action per line, but the unnecessary variable assignments break natural reading flow. Nesting is shallow, which helps. The parsing of the token and fallback loop are readable, but the timestamp calculation and hash slicing need cleanup. Overall, the code is maintainable but degraded by deliberate obfuscation of simple operations.

Run 1

Code Structure: Well-organized class with focused methods separating token generation, validation, configuration, and hashing. Nesting: Shallow overall; early returns keep validation readable, though the for-else construct requires attention. Clarity of intent: Descriptive method names and helpful documentation explain the main purpose, but arbitrary variables a through j obscure simple constants and date values. Code length: Mostly appropriate, although unnecessary variable assignments and arithmetic add avoidable length. Action granularity: Generally one action per line, with multiline calls formatted clearly; the hash slicing and arithmetic-heavy date construction are harder to parse. Reading flow: Methods follow a logical progression and validation steps are easy to follow, but artificial arithmetic and awkward slice formatting interrupt an otherwise natural flow.

Run 2

Code Structure: Well-organized class with focused methods separating token generation, validation, hashing, and configuration. Nesting: Mostly shallow, with early returns keeping validation readable; the loop's else clause requires some attention. Clarity of intent: Descriptive method names and useful documentation explain the overall purpose, but meaningless variables a–j and arithmetic expressions obscure simple constants such as the slicing step, zero microseconds, and epoch date. Code length: Generally appropriate, although artificial variable assignments and extensive wrapping add unnecessary length. Action granularity: Most lines perform a single action; chained hashing and slicing are somewhat harder to scan. Reading flow: Validation follows a natural parse, verify, and expiry-check sequence, but awkward slice formatting and indirect date construction interrupt the flow. Replacing the artificial arithmetic with direct constants would significantly improve readability.

Run 3

Code Structure: Well-organized class with focused methods separating token generation, validation, hashing, and configuration. Nesting: Mostly shallow; early returns simplify validation, although the for-else construct requires extra attention. Clarity of intent: Descriptive method names, docstrings, and comments explain the purpose, but meaningless variables a through j obscure straightforward constants such as the slice step, zero microseconds, and epoch date. Code length: Generally appropriate, though these unnecessary assignments add clutter. Action granularity: Most lines perform one clear action; chained hashing and awkwardly formatted slicing slightly complicate interpretation. Reading flow: Validation proceeds naturally from parsing to signature verification and expiration checks, but artificial arithmetic and fragmented expressions interrupt otherwise clean flow.