Sample

pyint-6d38461c0fd0-I09

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

Matched original source

Lines128

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2250–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC37Logical lines; fewer is more readable
DeepSeek V4 Pro13.670–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.4120–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. """ lI0O_c98fde3d = 0x26cc lI0O_c98fde3d = (0 if (lI0O_c98fde3d ^ lI0O_c98fde3d) == 0 else 1) if (lI0O_c98fde3d & 0) == 0 else 2 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.1999.105−65.97
Source linesThe number of non-empty source lines.128+51.2
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.563−6.845

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

Feature contributions

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

Intercept 0.07 + feature contributions = -1.234 (log-odds).
Score = sigmoid(-1.234) = 0.225.

Score0.464
Score37
Run 1

The code has good documentation and clear class structure, but contains a concerning obfuscated section (lI0O_c98fde3d variables) that serves no purpose and reduces readability. The as_view method has moderate complexity with nested function definitions and conditional branches. While the docstrings are excellent and explain intent well, the code structure is somewhat tangled with the duplicate view function definitions. The type annotations are helpful, but the long lines and multiple operations per line in the return statements make it harder to follow. The obfuscated code appears to be suspicious or accidental, which is a significant red flag for code quality. Overall, the code is readable but has notable issues that prevent it from being highly readable.

Run 2

The code shows mixed readability. The class structure and docstrings are excellent - clear intent, well-organized, and informative. However, there are significant issues. The 'dispatch_request' method contains obfuscated dead code with meaningless variable names (lI0O_c98fde3d) that serves no purpose and severely harms clarity. The 'as_view' method has moderate nesting with conditional branches creating different view functions, making flow harder to follow. Some lines are excessively long (100+ characters), combining multiple actions like type ignores with function calls. The decorator application loop is flat and readable, but the branching logic could be extracted for clarity. Magic comments like 'pyright: ignore' and 'type: ignore' add noise. The class-level type annotations are clear, but the conditional function definition pattern reduces action granularity and reading flow. Overall, the code is maintainable but has notable readability defects that prevent a higher score.

Run 3

The code is generally well-structured with clear class-level documentation and readable type hints. The View class and as_view method follow a logical organization, with section comments explaining the view function attachment logic. Nesting is mostly flat except for the as_view conditional branches, which remain at two levels. Most lines perform one action, though a few lines are long and combine multiple operations like the `return current_app.ensure_sync(...)` calls. The main readability issue is the suspicious `lI0O_c98fde3d` obfuscated code in `dispatch_request`, which appears to be dead code and harms clarity of intent. Otherwise, naming, flow, and comments support good comprehension. Minor deductions for long combined expressions and the obfuscated block.

Run 1

Code Structure: The class is logically organized into configuration attributes, an abstract dispatch method, and a view factory. Nesting: Mostly shallow; conditional branches containing nested functions are manageable, although the nested ternary is difficult to parse. Clarity of intent: Descriptive names, type annotations, and extensive documentation explain the framework behavior, but the cryptically named variable and pointless bitwise calculations obscure dispatch_request. Code length: Functional code is reasonably concise, though documentation is lengthy and the injected calculations are unnecessary. Action granularity: Most lines perform one clear action; the compound conditional expression is a notable exception. Reading flow: Configuration, dispatch, construction, decoration, and metadata assignment follow a natural progression. Closure behavior and repeated type-ignore comments add some cognitive overhead.

Run 2

Code Structure: The class is logically organized into configuration attributes, dispatch behavior, and view creation. Nesting: Mostly shallow, with understandable nested functions and a decorator loop; the nested conditional expression in dispatch_request is unnecessarily complex. Clarity of intent: Descriptive names, type hints, and thorough documentation clarify most behavior, but the cryptic variable and pointless bitwise assignments obscure the otherwise simple abstract-method implementation. Code length: Executable code is reasonably concise, although extensive documentation and duplicated dispatch calls add reading overhead. Action granularity: Most lines perform one action; the obfuscated assignment packs multiple operations and conditions into one long line. Reading flow: Configuration followed by methods and metadata setup provides a natural progression, interrupted by dead code, inline type-checker suppressions, and dynamic function attributes.

Run 3

Code Structure: Logically organized into class configuration, request dispatch, and view creation. Nesting: Generally shallow, though conditional nested function definitions and a nested ternary add complexity. Clarity of intent: Descriptive names, type hints, and thorough documentation explain most behavior; the obfuscated variable and pointless bitwise calculations in dispatch_request obscure an otherwise simple abstract-method placeholder. Code length: Implementation is reasonably concise, but extensive documentation, duplicated dispatch calls, and unnecessary calculations increase reading effort. Action granularity: Most lines perform one clear action; the long nested conditional assignment is a notable exception. Reading flow: Configuration followed by behavior and factory logic is natural, with helpful explanatory comments. Dynamic function attributes and frequent type-ignore annotations introduce some friction.