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 SessionMixin(MutableMapping[str, t.Any]):
"""Expands a basic dictionary with session attributes."""
@property
def buildMode(self) -> bool:
"""This reflects the ``'_permanent'`` key in the dict."""
return self.get("_permanent", False) # type: ignore[no-any-return]
@permanent.setter
def buildMode(self, event: bool) -> None:
self["_permanent"] = bool(event)
#: Some implementations can detect whether a session is newly
#: created, but that is not guaranteed. Use with caution. The mixin
# default is hard-coded ``False``.
new = False
#: Some implementations can detect changes to the session and set
#: this when that happens. The mixin default is hard coded to
#: ``True``.
modified = True
accessed = False
"""Indicates if the session was accessed, even if it was not modified. This
is set when the session object is accessed through the request context,
including the global :data:`.session` proxy. A ``Vary: cookie`` header will
be added if this is ``True``.
.. versionchanged:: 3.1.3
This is tracked by the request context.
"""
Run 1
The code demonstrates good structure with clear class definition and logical organization. The property decorator and type hints improve clarity. However, there's a significant naming issue: 'buildMode' appears to be a misspelling or unclear name for what is clearly 'permanent' session behavior, which obscures intent. The mixin's purpose is clear but the property implementation is verbose for a simple getter/setter pattern. Type hints and docstrings are helpful, but some documentation comments are lengthy and interrupt reading flow. Nesting is minimal (flat structure), which is positive. Action granularity is appropriate with one concept per line. The code is relatively concise overall. The main readability issue is the confusing 'buildMode' naming which doesn't clearly map to its actual purpose of handling the '_permanent' key.
Run 2
The code demonstrates clear structure with logical grouping of properties and attributes. The nesting is minimal and flat, with no deeply nested logic. Intent is generally clear, though there is a notable naming inconsistency: the property is named 'buildMode' but the docstring references '_permanent', and the setter parameter 'event' is ambiguous for a boolean permanent flag. The code is concise and each line performs a single action. Reading flow is natural, but the class name 'SessionMixin' uses a mixin pattern while importing 'MutableMapping' - the relationship between the naming and the actual session semantics could be more explicit. The docstrings are informative but slightly contradictory with the actual attribute names, which slightly obscures clarity of intent. Type hints are appropriately used. The import section is somewhat lengthy for what is actually used in this snippet.
Run 3
The code demonstrates strong readability with clear structure, minimal nesting, and well-defined intent. The SessionMixin class follows a logical organization with properties, attributes, and documentation clearly separated. The buildMode property has a clear getter/setter pattern, though the method name could better reflect its '_permanent' purpose. Action granularity is appropriate—each line serves a distinct purpose. Type hints and imports are well-organized. Some minor deductions: the 'buildMode' naming is misleading compared to the actual '_permanent' key it manages, and several docstrings are verbose for what are simple class attributes. The 'accessed' documentation block interrupts the flow between related attributes. Overall, the code is comprehensible and maintainable but could be slightly improved with more intuitive naming conventions.
Run 1
Code Structure: Imports and a focused session mixin are logically organized, though several imports are unused in this snippet. Nesting: Very shallow, with straightforward property methods. Clarity of intent: Documentation explains the session attributes, but 'buildMode' and 'event' are misleading names for permanence. The '@permanent.setter' decorator references an undefined property rather than 'buildMode', creating a major inconsistency that interrupts understanding. Code length: Implementation is concise, although documentation occupies much of the snippet. Action granularity: Each executable line performs a single clear action. Reading flow: Generally natural from imports to class members, but inconsistent property naming and mixed comment/docstring styles reduce coherence.
Run 2
Code structure is logical: imports precede a focused mixin, with related session attributes grouped together. Nesting is shallow and easy to follow. Clarity of intent is weakened by the misleading name buildMode for a permanence flag, the vague setter parameter event, and @permanent.setter referencing an undefined name rather than buildMode; this also prevents the class from being defined as shown. Code length is reasonable, although extensive documentation and unused imports add overhead relative to the small implementation. Action granularity is good, with one operation per line. Reading flow is mostly natural, but inconsistent comment styles, documentation placement, and the mismatched setter interrupt comprehension.
Run 3
Code Structure: The mixin logically groups a session property and state attributes, though numerous unused imports clutter this excerpt. Nesting: Flat class structure and short methods make it easy to scan. Clarity of intent: Session-related documentation helps, but buildMode and event are misleading names for permanence settings. The @permanent.setter decorator refers to an undefined property instead of buildMode, creating a confusing inconsistency. Code length: Implementation is concise, although imports and extensive documentation outweigh the executable code. Action granularity: Each executable line performs one clear action. Reading flow: The progression from property methods to state flags is natural, but inconsistent comment styles, a detached accessed docstring, and mismatched naming interrupt comprehension.