Sample

pyint-c5769bc33c9f-I13

Lower every eligible synchronous for loop to a while loop

Matched original source

Lines131

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.4710–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC39Logical lines; fewer is more readable
DeepSeek V4 Pro10.670–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.6160–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__ loopIterator = __import__("builtins").iter(cls.decorators) while True: try: decorator = __import__("builtins").next(loopIterator) except __import__("builtins").StopIteration: break 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.2017.905−66.591
Source linesThe number of non-empty source lines.131+52.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.505−6.758

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.132−3.637
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.130.928+1.42
Indentation frequencyHow rapidly indentation changes from line to line.51+1.027
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.97−0.993
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.97+0.97
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.032+0.63
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.115 (log-odds).
Score = sigmoid(-0.115) = 0.471.

Score0.464
Score39
Run 1

The code is generally structured but has readability issues. The class and method organization is logical, and documentation is thorough. However, the `as_view` method contains an unnecessary while loop with explicit `__import__("builtins")` calls instead of a simple for loop, which harms clarity. The nested function and conditional branches increase complexity. Lines are long, with type ignore comments adding noise. While the code is functional, the unnatural loop pattern and verbose builtins access make it harder to follow than necessary.

Run 2

The code is generally readable, with clear class structure, type hints, and comprehensive documentation. However, several issues reduce readability. The decorator application block uses an overly convoluted while loop with repeated '__import__("builtins")' calls instead of a simple 'for decorator in cls.decorators' loop, violating action granularity and reading flow. Nesting is acceptable but the conditional as_view logic could be flatter. Line length in some areas, like the ensure_sync calls, is excessive. Intent is mostly clear but obscured in the decorator loop. Overall, the code is well-organized, but the awkward loop and some verbose lines prevent a higher score.

Run 3

The code has some readable elements like clear class attributes, docstrings, and method separation, but it is severely undermined by the `as_view` method. The decorator application logic uses an obscure `while True` loop with `__import__('builtins')` calls instead of a simple `for` loop, making intent hard to follow. There is unnecessary type-ignore noise scattered throughout. The conditional branches inside `as_view` create duplicated view definitions, reducing clarity. The natural reading flow is interrupted by low-level constructs and awkward variable names like `loopIterator`. Action granularity is mixed; some lines pack multiple operations. Overall structure is logical at the class level, but the core method is tangled and verbose, leading to poor readability.

Run 1

Code Structure: The class is logically organized into configuration attributes, request dispatch, and view creation. Nesting: Mostly shallow, but nested function definitions and the decorator loop's while/try/except add complexity. Clarity of intent: Descriptive names, type hints, and thorough documentation explain behavior well; dynamic function attributes and repeated builtins imports are less intuitive. Code length: Implementation is reasonably compact, but documentation is extensive and the manual iterator loop is unnecessarily longer than a simple for loop. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Configuration-to-dispatch-to-factory ordering is natural, and metadata assignment is grouped coherently. However, the unusual decorator iteration, duplicated wrapper logic, and long lines with type-ignore comments interrupt otherwise clear reading.

Run 2

Code Structure: The class is logically organized into configuration attributes, dispatch behavior, and view creation. Nesting: Mostly shallow, but nested closures and the decorator loop's try/except add complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the purpose well; dynamic function attributes and repeated builtins imports are less intuitive. Code length: Implementation is reasonably compact, but extensive documentation and manually expanded iteration increase reading effort. Action granularity: Statements generally perform one action per line, although chained synchronization and dispatch calls are somewhat dense. Reading flow: Configuration-to-behavior progression is natural, but the unusual loopIterator naming and while/next/StopIteration pattern interrupt it. A standard for loop would make decorator application substantially clearer.

Run 3

Code Structure: Well-organized class with clearly separated configuration, dispatch behavior, and view construction. Nesting: Generally moderate, but nested function definitions and the decorator loop's while/try/except structure add complexity. Clarity of intent: Descriptive names, type annotations, and detailed documentation explain the lifecycle and metadata; dynamic builtins imports and loopIterator obscure otherwise simple iteration. Code length: Most implementation is concise, but extensive documentation and manually expanded iterator handling increase scanning effort. Action granularity: Statements generally perform one action per line, although chained ensure_sync calls require extra interpretation. Reading flow: Configuration-to-dispatch-to-factory ordering is natural, but repeated view definitions, long type-ignore lines, and the unconventional decorator loop interrupt the flow. A standard for loop would substantially improve readability.