Sample

pyint-55d5054808f0-I06

Invert eligible conditions and exchange their branches

Matched original source

Lines127

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2750–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC36Logical lines; fewer is more readable
DeepSeek V4 Pro120–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.5810–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 not (cls.init_every_request): 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] else: 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] # type: ignore[no-any-return] if not (cls.decorators): pass else: 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.1844.924−60.882
Source linesThe number of non-empty source lines.127+50.8
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.513−6.769

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.128−3.496
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.140.984−2.306
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.140.977+1.47
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.126.845+1.363
Indentation frequencyHow rapidly indentation changes from line to line.47+0.889
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.031+0.643
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.969 (log-odds).
Score = sigmoid(-0.969) = 0.275.

Score0.464
Score36
Run 1

The code has good documentation and type hints, but its structure suffers from unclear conditionals and repetitive setup. The `as_view` method uses inverted conditionals like `if not (cls.init_every_request)` instead of the clearer `if cls.init_every_request`. The `if not (cls.decorators): pass` block is especially confusing — an empty `pass` branch with work in the `else` is a backwards pattern that hurts readability. Nesting is moderate but the conditional branches make the flow disorganized. Clarity is further reduced by the two different `view` function definitions, which share many lines but are not factored out. Action granularity is mostly one action per line, and the final attribute assignments are linear, which helps. However, the odd conditionals, duplicated type-ignore comments, and the unnecessary `pass` branch lower the score. Overall, the code is maintainable by experienced developers but not as readable as it should be given the straightforward logic.

Run 2

The code is generally readable due to extensive docstrings, clear naming, and logical organization. The View class structure is straightforward, and type annotations aid comprehension. However, the as_view method exhibits asymmetric branching, using 'if not (condition)' with pass/else, which inverts readability. The else branch contains deeply nested logic within a closure and has a duplicated comment plus multiple type-ignore statements. The return current_app.ensure_sync(...) line is long and performs multiple actions, reducing action granularity. Minimal comments explain complex behavior, and the contrast between well-documented class attributes and dense method logic disrupts flow. While functional, the conditional logic and nesting could be simplified to improve readability.

Run 3

The code is generally well-structured with clear class-level documentation and logical organization. It uses type hints and separation of concerns effectively. However, readability is hindered by some awkward control flow: the 'if not cls.decorators: pass else:' pattern is unnecessarily convoluted, and the conditional branching in as_view creates two similar view functions. There are redundant type-ignore comments and duplicated return lines. Nesting is mostly flat, and intent is clear from docstrings, but the decorator handling could be simpler. Action granularity is acceptable, though some lines combine multiple operations. The reading flow is natural overall.

Run 1

Code Structure: Logically organized into configuration attributes, the dispatch interface, and view creation. Nesting: Mostly shallow, though conditional nested function definitions require some attention. Clarity of intent: Descriptive names, type annotations, and thorough documentation clearly explain behavior; dynamic function attributes and closures add complexity. Code length: Implementation is reasonably concise, but extensive documentation, duplicated dispatch calls, and an unnecessary pass branch increase length. Action granularity: Generally one action per line, with no compressed multi-statement lines; chained ensure_sync invocation is slightly denser. Reading flow: Natural progression from configuration to execution and metadata assignment, interrupted by inverted conditions, redundant parentheses, long type-ignore comments, and a duplicated suppression comment.

Run 2

Code Structure: Logically organized into configuration attributes, an abstract dispatch method, and a view factory. Nesting: Mostly shallow, although conditional nested function definitions add some complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain behavior well; dynamic function attributes and type-ignore comments introduce friction. Code length: Implementation is reasonably concise, but extensive documentation, duplicated dispatch calls, and a redundant conditional/pass block increase length. Action granularity: Statements generally perform one action per line, with readable multiline calls. Reading flow: Progresses naturally from configuration to view creation and metadata assignment, but negated conditions with unnecessary parentheses, the empty branch, and duplicated type-ignore annotations interrupt the flow.

Run 3

Code Structure: Well-organized class with documented configuration attributes and focused methods. Nesting: Generally shallow, though conditional nested view functions add some complexity. Clarity of intent: Descriptive names, type annotations, and extensive documentation clearly explain behavior; dynamic function attributes require closer reading. Code length: Implementation is reasonably concise, but lengthy documentation, duplicated dispatch calls, and a redundant pass branch add bulk. Action granularity: Most lines perform one clear action; chained ensure_sync invocation is slightly denser. Reading flow: Progresses naturally from configuration to dispatch and view creation, but negated conditions with unnecessary parentheses, the empty decorator branch, and repeated type-ignore comments interrupt the flow.