Sample

pyint-3139ee945c70-I10

Deterministically remove some optional blank lines and bracketed line breaks

Matched original source

Lines116

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.4520–1; higher is more readable
Mi0.3650–1; higher is more readable
LLOC35Logical lines; fewer is more readable
DeepSeek V4 Pro14.330–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.6390–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.116+46.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.514−6.772

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.117−3.106
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.115.847+1.209
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.966−0.993
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.991+0.97
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.03+0.648
Indentation frequencyHow rapidly indentation changes from line to line.39+0.612
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.191 (log-odds).
Score = sigmoid(-0.191) = 0.452.

Score0.365
Score35
Run 1

The code is generally structured and documented, but readability is hurt by inconsistent formatting, dense class-level docstrings, and some awkward line breaks. The positive aspects: clear class design, docstrings explaining intent, and mostly flat logic. The negatives: the `as_view` method contains nested function definitions and repeated `return current_app.ensure_sync(...)` lines, making it harder to scan. There are also misaligned line breaks (e.g., `view.view_class` and the long line inside `view`), and multiple type-ignore comments interrupt reading flow. The class-level comments are verbose and sometimes break the visual grouping of attributes. Overall, the code is understandable for experienced Flask developers, but it requires effort to parse due to formatting inconsistencies and multipurpose sections. Score: 13.

Run 2

The code is generally readable with clear structure and intent. The View class is well-documented, and the as_view method follows a logical flow. However, there are a few issues: inconsistent indentation in the first branch of the conditional, occasional dense lines with multiple operations (e.g., type ignores and returns), and slightly unclear separation between branches. The nesting is shallow, which is good. Action granularity is mostly one action per line, but some lines combine function calls and type comments. Overall, it is maintainable but could benefit from minor formatting consistency improvements.

Run 3

The code is generally readable but has issues. Class variables with docstrings are well organized, and the `as_view` method follows a logical flow. However, there are problems with action granularity and nesting. The `view` function definitions inside `as_view` create nested functions, and lines like `self = view.view_class(*class_args, **class_kwargs)` mix type ignores with awkward spacing. The `ensure_sync(self.dispatch_request)(**kwargs)` call chains multiple actions on one line, reducing clarity. Reading flow is adequate but interrupted by long comments and type annotations. The branching between `init_every_request` paths adds complexity, though not deeply nested. Overall, the code is functional and documented but lacks consistent formatting and would benefit from cleaner line breaks and reduced chained method calls.

Run 1

Code Structure: Well-organized class with configuration attributes, an abstract dispatch method, and a view factory. Nesting: Mostly shallow; nested closures and a decorator loop add manageable complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain request handling and instance lifetimes, although dynamic function attributes and type-ignore comments require extra attention. Code length: Implementation is reasonably concise, but extensive documentation and repeated metadata assignments increase reading length. Action granularity: Most lines perform one action; chained ensure_sync calls slightly compress multiple operations. Reading flow: Progresses naturally from configuration to behavior to factory construction, but inconsistent blank lines, awkward argument formatting, and long inline comments interrupt the flow.

Run 2

Code Structure: The class logically groups configuration, dispatch behavior, and view construction, although spacing between sections is inconsistent. Nesting: Conditional branches and nested view functions add moderate, justified complexity without excessive depth. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the purpose well; dynamic function attributes and type-ignore comments require extra attention. Code length: Implementation is reasonably concise, but extensive documentation and duplicated wrapper logic lengthen the reading experience. Action granularity: Statements generally perform one action per line, with clear individual metadata assignments. Reading flow: Execution proceeds naturally from instance creation to decoration and metadata assignment. Irregular formatting around constructor arguments, long return lines, and limited blank lines slightly disrupt readability.

Run 3

Code Structure: The class cleanly separates configuration, request dispatch, and view creation. Nesting: Mostly shallow, although conditional nested functions and a decorator loop add moderate complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain behavior well; dynamic function attributes and type-ignore comments require extra attention. Code length: Executable code is concise, but extensive documentation and repeated metadata assignments increase reading length. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Configuration progresses naturally into dispatch and factory logic, but inconsistent blank lines, awkward constructor formatting, and long return statements interrupt the flow.