Sample

pyint-4b7ddd80e522-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines129

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2260–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC38Logical lines; fewer is more readable
DeepSeek V4 Pro160–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.4380–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: factorial = 1 for current_factor in range(2, 5): factorial *= current_factor 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.1918.114−63.298
Source linesThe number of non-empty source lines.129+51.6
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.501−6.751

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.130−3.567
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.128.874+1.392
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.977−0.993
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.977+0.97
Indentation frequencyHow rapidly indentation changes from line to line.49+0.958
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.49−0.704
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.031+0.643

Intercept 0.07 + feature contributions = -1.231 (log-odds).
Score = sigmoid(-1.231) = 0.226.

Score0.464
Score38
Run 1

The code is reasonably readable with good structure, clear intent, and helpful documentation. Class variables, type hints, and docstrings improve clarity. Nesting is mostly shallow except for the if/else in `as_view`, which remains understandable. However, a major issue is a stray, unrelated factorial loop inside the `view` function, which breaks clarity and relevance. Additionally, some lines are dense—especially those mixing function calls with type ignores—and the `as_view` method handles multiple responsibilities (view creation, decoration, metadata assignment), reducing cohesion. But overall, logical organization and action granularity are moderate.

Run 2

The code is highly readable due to its clear logical organization, comprehensive docstrings, and type annotations. The View class is well-structured with class-level constants and a clean classmethod. Nesting is minimal, with only a single conditional and small nested function definitions. Intent is explicitly documented, especially in the docstring and comments. Code length is appropriate given the educational nature and necessary metadata. Each action is on its own line, improving clarity. The only minor readability drawbacks are slightly long function signatures and the unusual inline factorial loop, which may distract from the primary purpose. Overall, the code is maintainable, self-explanatory, and follows consistent style conventions.

Run 3

The code is generally well-structured with clear class-level documentation and type hints, making the intent understandable. However, there are some readability issues: the `as_view` method has a nested function with an unrelated factorial computation that breaks the natural reading flow and adds confusion. The method mixes setup logic (creating instances, applying decorators, attaching attributes) with the view function definition, making the action granularity uneven. The nesting is moderate, with conditional branches containing function definitions, but it could be flatter. The code length is acceptable but could be shorter if the factorial loop were removed. Overall, the code is readable for experienced developers familiar with Flask internals, but the unrelated computation and slightly tangled flow prevent a higher score.

Run 1

Code Structure: The class cleanly groups configuration, dispatch behavior, and view creation, though an unrelated factorial calculation disrupts cohesion. Nesting: Mostly shallow, with understandable conditional closures and loops; the factorial loop adds needless nesting. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the lifecycle and decorators well, but the unused factorial calculation is confusing. Code length: Executable logic is reasonably concise, although extensive documentation and repeated metadata assignments increase reading effort. Action granularity: Statements generally perform one action per line; chained dispatch calls remain understandable. Reading flow: Configuration proceeds naturally into dispatch and factory logic, but dynamic function attributes, type-ignore comments, and the irrelevant calculation interrupt an otherwise coherent flow.

Run 2

Code Structure: Logically organized into documented configuration attributes and focused methods; the unrelated factorial calculation disrupts cohesion. Nesting: Generally shallow, although conditional nested functions and the factorial loop add complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the view lifecycle well; the unused factorial calculation is confusing, and dynamic function attributes require extra interpretation. Code length: Implementation is reasonably concise, but extensive documentation, repeated metadata assignments, and dead computation increase reading effort. Action granularity: Most lines perform one action; the combined ensure_sync and dispatch invocation is denser but understandable. Reading flow: Progresses naturally from configuration to dispatch and view construction, with clear branching for instance lifetime. Closure behavior, inline type-checker suppressions, and the irrelevant loop interrupt an otherwise coherent flow.

Run 3

Code Structure: Logically organized into class configuration, dispatch behavior, and view creation, although the unrelated factorial calculation disrupts cohesion. Nesting: Moderate nesting from conditional branches, inner functions, and loops remains manageable. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the class-based view mechanism; the unused factorial computation has no clear purpose. Code length: Implementation is reasonably concise, but extensive documentation and repeated metadata assignments increase reading length. Action granularity: Statements generally perform one action per line; chained dispatch calls are slightly denser. Reading flow: Configuration precedes behavior naturally, and comments explain dynamic attributes. However, closure behavior, duplicated inner-function definitions, numerous type-ignore annotations, and irrelevant arithmetic interrupt an otherwise clear flow.