Sample

pyint-f1c66b57ce26-I12

Inline all eligible single-use intermediate local variables

Matched original source

Lines126

Scores

MethodScoreScale
Posnett0.0030–1; higher is more readable
Dorn0.4580–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC34Logical lines; fewer is more readable
DeepSeek V4 Pro160–20; mean of three runs
GPT-6.1 Sol16.670–20; mean of three runs
BTTF0.6070–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: return current_app.ensure_sync((view.view_class( # type: ignore[attr-defined] *class_args, **class_kwargs )).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.1771.472−58.459
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.518−6.777

Intercept 8.87 + feature contributions = -5.965 (log-odds).
Score = sigmoid(-5.965) = 0.003.

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.82+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.109.992−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.031+0.645
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.168 (log-odds).
Score = sigmoid(-0.168) = 0.458.

Score0.464
Score34
Run 1

The code is well-structured with clear class-level attributes and docstrings. Methods are separated logically, and the `as_view` function uses a flat if/else for init behavior, keeping nesting shallow. Type hints and comments improve clarity. However, the `as_view` method is somewhat dense, with multi-action lines (e.g., nested function call chaining) and inline type ignores that add noise. Line length and inline comments like `# We attach the view class...` help intent but the `view` inner function definitions slightly disrupt reading flow. Overall readable but could be more concise.

Run 2

The code is generally well-structured with clear class-level documentation, appropriate type hints, and logical separation of concerns. The docstrings are detailed and helpful, which improves clarity of intent. However, readability suffers in the `as_view` method: the nested function definitions and the complex expression combining `current_app.ensure_sync`, class instantiation, and method dispatch on a single line make it harder to parse. There is also some duplication between the two branches of the conditional, and several `type: ignore` comments add visual noise. Nesting is moderate but the dense logic in `view` functions reduces readability. Action granularity is inconsistent — some lines pack multiple operations while others are well separated. Overall, it is readable for experienced developers familiar with Flask internals, but could be simplified by extracting helper methods or breaking down complex expressions into intermediate variables.

Run 3

The code is highly readable with clear structure and intent. It uses logical class organization, descriptive names, and concise docstrings that explain its purpose. Nesting is minimal, though the `current_app.ensure_sync` call is slightly dense with inline comments. Action granularity is mostly one action per line, but some lines combine multiple operations (e.g., the dispatch call). The reading flow is natural, and the code length is justified by necessary documentation and configuration attributes. Minor reductions in nested function call complexity and denser inline comments would improve clarity.

Run 1

Code Structure: The class is logically organized into configuration attributes, an override hook, and a view factory. Nesting: Mostly shallow, although conditional nested function definitions and a decorator loop add moderate complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the lifecycle and configuration well; dynamic function attributes require closer attention. Code length: Executable code is reasonably concise, but extensive documentation and repeated metadata assignments lengthen the reading path. Action granularity: Most lines perform one action, but the per-request return expression combines instantiation, method lookup, synchronization, and invocation, making it harder to parse. Reading flow: Generally natural and sequential, with the dense multiline return expression, inline type-ignore comments, and an extra blank line interrupting flow.

Run 2

Code Structure: Logically organized into configuration attributes, an override hook, and a view factory. Nesting: Mostly shallow, with understandable conditional function definitions and a decorator loop. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain lifecycle choices and metadata attachment; dynamic function attributes add some complexity. Code length: Implementation is compact, although extensive documentation and repeated metadata assignments increase reading time. Action granularity: Most lines perform one action, but the per-request return expression combines instantiation, method lookup, synchronization, and invocation, making it harder to parse. Reading flow: Generally natural and sequential, but awkward expression wrapping, inline type-ignore comments, and extra whitespace interrupt an otherwise clean flow.

Run 3

Code Structure: Well-organized class with configuration attributes, a dispatch contract, and a view factory. Nesting: Moderate and justified, primarily conditional branches containing closures and a decorator loop. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain lifecycle behavior and metadata. However, dynamic function attributes and the compressed instance-creation/dispatch expression require extra interpretation. Code length: Implementation is reasonably concise; extensive documentation adds scanning overhead but provides useful context. Action granularity: Most lines perform one action, but the per-request return expression combines instantiation, method lookup, synchronization, and invocation. Reading flow: Generally natural, progressing from configuration to execution and metadata assignment. Awkward parentheses, long return lines, inline type-ignore comments, and redundant metadata assignments slightly disrupt the flow.