Sample

pyint-51028bef1232-I11

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

Matched original source

Lines126

Scores

MethodScoreScale
Posnett0.0020–1; higher is more readable
Dorn0.4590–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC35Logical lines; fewer is more readable
DeepSeek V4 Pro170–20; mean of three runs
GPT-6.1 Sol180–20; mean of three runs
BTTF0.6530–1; higher is more readable

Views

Source code

from __future__ import annotations import typing as t from . import typing as ft from .globals import current_app from .globals import request class View: """Subclass this class and override :meth:`dispatch_request` to create a generic class-based view. Call :meth:`as_view` to create a view function that creates an instance of the class with the given arguments and calls its ``dispatch_request`` method with any URL variables. See :doc:`views` for a detailed guide. .. code-block:: python class Hello(View): init_every_request = False def dispatch_request(self, name): return f"Hello, {name}!" app.add_url_rule( "/hello/<name>", view_func=Hello.as_view("hello") ) Set :attr:`methods` on the class to change what methods the view accepts. Set :attr:`decorators` on the class to apply a list of decorators to the generated view function. Decorators applied to the class itself will not be applied to the generated view function! Set :attr:`init_every_request` to ``False`` for efficiency, unless you need to store request-global data on ``self``. """ #: The methods this view is registered for. Uses the same default #: (``["GET", "HEAD", "OPTIONS"]``) as ``route`` and #: ``add_url_rule`` by default. methods: t.ClassVar[t.Collection[str] | None] = None #: Control whether the ``OPTIONS`` method is handled automatically. #: Uses the same default (``True``) as ``route`` and #: ``add_url_rule`` by default. provide_automatic_options: t.ClassVar[bool | None] = None #: A list of decorators to apply, in order, to the generated view #: function. Remember that ``@decorator`` syntax is applied bottom #: to top, so the first decorator in the list would be the bottom #: decorator. #: #: .. versionadded:: 0.8 decorators: t.ClassVar[list[t.Callable[..., t.Any]]] = [] #: Create a new instance of this view class for every request by #: default. If a view subclass sets this to ``False``, the same #: instance is used for every request. #: #: A single instance is more efficient, especially if complex setup #: is done during init. However, storing data on ``self`` is no #: longer safe across requests, and :data:`~flask.g` should be used #: instead. #: #: .. versionadded:: 2.2 init_every_request: t.ClassVar[bool] = True def dispatch_request(self) -> ft.ResponseReturnValue: """The actual view function behavior. Subclasses must override this and return a valid response. Any variables from the URL rule are passed as keyword arguments. """ raise NotImplementedError() @classmethod def as_view( cls, name: str, *class_args: t.Any, **class_kwargs: t.Any ) -> ft.RouteCallable: """Convert the class into a view function that can be registered for a route. By default, the generated view will create a new instance of the view class for every request and call its :meth:`dispatch_request` method. If the view class sets :attr:`init_every_request` to ``False``, the same instance will be used for every request. Except for ``name``, all other arguments passed to this method are forwarded to the view class ``__init__`` method. .. versionchanged:: 2.2 Added the ``init_every_request`` class attribute. """ if cls.init_every_request: def view(**kwargs: t.Any) -> ft.ResponseReturnValue: self = view.view_class( # type: ignore[attr-defined] *class_args, **class_kwargs ) return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return] else: self = cls(*class_args, **class_kwargs) # pyright: ignore def view(**kwargs: t.Any) -> ft.ResponseReturnValue: return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return] if cls.decorators: view.__name__ = name view.__module__ = cls.__module__ for decorator in cls.decorators: view = decorator(view) # We attach the view class to the view function for two reasons: # first of all it allows us to easily figure out what class-based # view this thing came from, secondly it's also used for instantiating # the view class so you can actually replace it with something else # for testing purposes and debugging. view.view_class = cls # type: ignore view.__name__ = name view.__doc__ = cls.__doc__ view.__module__ = cls.__module__ view.methods = cls.methods # type: ignore view.provide_automatic_options = cls.provide_automatic_options # type: ignore return view

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.1777.581−58.66
Source linesThe number of non-empty source lines.126+50.4
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.517−6.775

Intercept 8.87 + feature contributions = -6.165 (log-odds).
Score = sigmoid(-6.165) = 0.002.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.127−3.46
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.125.856+1.349
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.110−0.994
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.976+0.97
Indentation frequencyHow rapidly indentation changes from line to line.46+0.854
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.03+0.649
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.164 (log-odds).
Score = sigmoid(-0.164) = 0.459.

Score0.464
Score35
Run 1

The code is highly readable due to its clear class-based structure, comprehensive docstrings, and logical organization. The View class is well-documented with examples and version notes, making intent explicit. Function definitions are straightforward, and type hints improve clarity. Nesting is minimal—only one level in the as_view method's conditional blocks. The code is moderately concise, with some verbose type ignores and long lines that slightly reduce readability. Action granularity is generally good, though a few lines combine multiple operations (e.g., function calls with type ignores). Overall reading flow is natural, progressing logically from class attributes to methods. Minor deductions for occasional line length and type-ignore clutter.

Run 2

The code is highly readable overall. It is logically organized, with class variables and methods clearly separated. The docstrings are detailed and explain intent well. The `as_view` method shows slight nesting due to the `if cls.init_every_request` branch, but the branches are short and easy to follow. Action granularity is mostly one action per line; a few lines combine type ignores and assignments but remain understandable. The reading flow is natural, moving from class setup to dispatch behavior to the factory method. Minor length comes from extensive documentation, which is appropriate for a public API rather than unnecessarily long. The recursive decorator application and view metadata assignments are clear, though in a couple of spots, long lines with type ignores slightly reduce readability.

Run 3

The code is well-structured and highly readable, with clear separation of class-level documentation, type annotations, and method definitions. The `View` class includes extensive docstrings that explain purpose and usage, contributing to clarity of intent. Nesting is minimal, limited to one level inside conditional blocks and loops. Action granularity is mostly one action per line, though a few lines combine instantiation, type comments, and method calls. Reading flow is natural, following a logical sequence from class definition to method implementation. Code length is justified by educational/documentation content rather than unnecessary complexity. Minor readability reductions come from inline type-ignore comments and slightly dense lines in `as_view`, but overall the code is very readable.

Run 1

Code Structure: Well-organized class with configuration attributes, an abstract dispatch method, and a view factory. Nesting: Mostly shallow; conditional nested function definitions and the decorator loop add manageable complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation clearly explain behavior, including instance reuse. Dynamic function attributes and type-ignore comments require some extra interpretation. Code length: Implementation is concise, though extensive documentation and repeated wrapper logic slightly increase reading effort. Action granularity: Each statement generally performs one action, with metadata assignments clearly separated. Reading flow: Naturally progresses from configuration to dispatch and view creation; closures, decorator application, and metadata attachment introduce minor cognitive overhead.

Run 2

Code Structure: Logically organized into class configuration, an abstract dispatch method, and a view factory. Nesting: Shallow overall, with understandable nested functions and a decorator loop. Clarity of intent: Descriptive names, type annotations, and detailed documentation clearly explain behavior, though dynamic function attributes and closures require some familiarity. Code length: Implementation is concise; extensive documentation adds length but provides useful context. Minor duplication exists between the two generated view functions and metadata assignments. Action granularity: Each line generally performs one action, with no compressed multi-statement lines. Reading flow: Progresses naturally from configuration to request dispatch and callable setup. Long return lines, inline type-checker suppression comments, and repeated metadata assignments slightly interrupt the otherwise clear flow.

Run 3

Code Structure: Imports, configuration attributes, and methods are logically organized with clear responsibilities. Nesting: Limited to conditional branches, nested view functions, and a decorator loop; depth remains manageable. Clarity of intent: Descriptive names, type annotations, and comprehensive documentation explain instance lifecycle and route generation, though dynamic function attributes and closures require extra attention. Code length: Implementation is reasonably concise, but extensive documentation, repeated metadata assignments, and duplicated dispatch calls slightly increase reading effort. Action granularity: Statements generally perform one action per line; chained dispatch invocation is compact but understandable. Reading flow: Progresses naturally from class configuration to dispatch behavior and view construction. Long type-ignore comments and documentation markup occasionally interrupt the otherwise clear flow.