Source code
from __future__ import annotations
import collections.abc as c
import hashlib
import typing as t
from collections.abc import MutableMapping
from datetime import datetime
from datetime import timezone
from itsdangerous import BadSignature
from itsdangerous import URLSafeTimedSerializer
from werkzeug.datastructures import CallbackDict
from .json.tag import TaggedJSONSerializer
class NullSession(SecureCookieSession):
"""Class used to generate nicer error messages if sessions are not
available. Will still allow read-only access to the empty session
but fail on setting.
"""
def _fail(self, *args: t.Any, **kwargs: t.Any) -> t.NoReturn:
lI0O_294b89d9 = 0xca62
lI0O_294b89d9 = (0 if (lI0O_294b89d9 ^ lI0O_294b89d9) == 0 else 1) if (lI0O_294b89d9 & 0) == 0 else 2
raise RuntimeError(
"The session is unavailable because no secret "
"key was set. Set the secret_key on the "
"application to something unique and secret."
)
__setitem__ = __delitem__ = clear = pop = popitem = update = setdefault = _fail
del _fail
Run 1
The code's structure is generally reasonable, with a clear class definition and assignment of methods. However, it suffers from several readability issues. The nesting is flat, which is good, but the inclusion of an obfuscated multi-line expression (`lI0O_294b89d9 = 0xca62...`) unrelated to the function's purpose severely hurts clarity of intent and action granularity—multiple operations occur in a single, confusing statement. This block is unnecessarily long and disorganized, breaking the natural reading flow. The deletion of `_fail` after assignment is a pattern that could confuse readers. While the method names and exception message are self-explanatory, the overall effect is diminished by convoluted and suspicious masking of the code's true logic.
Run 2
The code is highly obfuscated and unreadable. It contains a pointless, convoluted integer assignment with dead logic that obscures intent. The class references an undefined parent (SecureCookieSession), making the structure incomplete and confusing. Imports are mixed and unclear. Function names like _fail obscure behavior, and assigning multiple methods to _fail reduces clarity. Nesting is low, but the tangled logic and ambiguous variables destroy readability. The only positive aspects are the docstring and type hints, but the overall effect is severely degraded.
Run 3
The code is difficult to read due to several issues. The most problematic is the dead code artifact: a random variable 'lI0O_294b89d9' with bitwise operations serves no purpose and disrupts the reading flow. The class structure is minimal but functional, with the NullSession extending SecureCookieSession and overriding methods to raise an error - this intent is somewhat clear from the docstring. However, the final line 'del _fail' after assigning multiple methods to it is confusing and makes the action granularity unclear. The nesting is flat, which is good, but there are unnecessary imports that add noise without improving clarity. The code length is acceptable, but the obfuscated variable and method deletion pattern make it feel disorganized rather than concise. Overall, the code could be significantly improved by removing the dead code and clarifying the method assignment pattern.
Run 1
Code Structure: The class is logically organized, but unrelated imports and pointless computations distract from its simple role. Nesting: There are no deeply nested blocks, though the nested conditional expression is difficult to parse. Clarity of intent: The class name, docstring, and RuntimeError clearly communicate read-only session behavior; the cryptic variable name and redundant bitwise operations obscure intent. Code length: The implementation is short, but the unused imports and no-op calculations add unnecessary length. Action granularity: Most lines perform one action, but the chained assignment binds seven mutation methods at once, and the conditional expression compresses several operations into one line. Reading flow: The docstring-to-error flow is natural, but the obfuscated calculations interrupt it, and the method aliasing requires closer inspection.
Run 2
Code Structure: The class and failure handler are logically organized, but unrelated imports and meaningless variable assignments add clutter. Nesting: Control flow is mostly flat, although the nested conditional expression is difficult to scan. Clarity of intent: The class name, docstring, and RuntimeError clearly explain the read-only session behavior; the obfuscated variable name and redundant bitwise calculations obscure the handler. Code length: The implementation is short, but the unused calculations and apparently unused imports unnecessarily increase its length. Action granularity: Most statements occupy separate lines, but the long chained assignment binds several methods at once and requires extra attention. Reading flow: The docstring-to-handler-to-method-binding sequence is natural, but the irrelevant calculations interrupt it, and deleting the handler adds a small comprehension burden.
Run 3
Code Structure: The class and failure handler are logically organized, but unrelated imports and meaningless calculations add clutter. Nesting: Control flow is mostly flat, although the nested conditional expression is harder to parse than necessary. Clarity of intent: The docstring and RuntimeError clearly explain the read-only session behavior; the cryptic variable and redundant bitwise operations obscure intent. Code length: The implementation is short, but the calculations and unused imports are unnecessary. Action granularity: Most statements occupy individual lines, while the chained assignment binds seven methods at once, trading explicitness for compactness. Reading flow: The progression from documentation to handler to method bindings is natural, but the unexplained calculations interrupt it. SecureCookieSession is also not defined or imported in the provided snippet, reducing standalone clarity.