Sample

pyint-60c7c66acc86-I07

Insert deterministic runtime-dead branches into callable bodies

Matched original source

Lines134

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2090–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC43Logical lines; fewer is more readable
DeepSeek V4 Pro12.330–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.4730–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. """ if ((0xbd21 ^ 0xbd21) != 0): raise AssertionError() 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 ((0xf0d4 ^ 0xf0d4) != 0): raise AssertionError() if cls.init_every_request: def view(**kwargs: t.Any) -> ft.ResponseReturnValue: if ((0xfa49 ^ 0xfa49) != 0): raise AssertionError() 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: if ((0x46a2 ^ 0x46a2) != 0): raise AssertionError() 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.2199.642−72.588
Source linesThe number of non-empty source lines.134+53.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.534−6.802

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.135−3.744
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.133.874+1.461
Indentation frequencyHow rapidly indentation changes from line to line.54+1.131
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.948−0.992
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.963+0.97
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.54−0.818
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.036+0.592

Intercept 0.07 + feature contributions = -1.33 (log-odds).
Score = sigmoid(-1.33) = 0.209.

Score0.464
Score43
Run 1

The code is generally well-structured with clear documentation and logical separation of concerns. However, readability is reduced by several issues: the obfuscated `if ((0xbd21 ^ 0xbd21) != 0): raise AssertionError()` blocks are confusing and add noise. The `as_view` method has moderate nesting and branches create two separate `view` function definitions, which interrupts reading flow. Action granularity is mostly one action per line, but some lines are densely packed with type ignores and long chained calls (e.g., `return current_app.ensure_sync(self.dispatch_request)(**kwargs)`). The extensive docstrings are helpful but add significant length. The use of `typing as t` and `from . import typing as ft` is consistent, though imports could be consolidated. Overall, the code is maintainable but could benefit from removing artificial obfuscation, simplifying the conditional branches, and breaking up complex lines for better clarity.

Run 2

The code is generally well-structured and readable. It uses clear class-level attributes with thorough docstrings, type hints, and a logical separation between dispatch_request and as_view. The nesting is minimal, with only one level inside the conditional branches of as_view. Intent is clear from method and variable names. However, readability is harmed by the presence of obfuscated no-op checks like `if ((0xbd21 ^ 0xbd21) != 0): raise AssertionError()`, which add noise and confusion. Action granularity is mostly good, though some lines (e.g., `return current_app.ensure_sync(...)`) combine multiple operations. The reading flow is natural for the most part, but the repeated no-op assertions disrupt it. Overall, the code is readable but would be improved by removing the dead/obfuscated checks and slightly simplifying certain dense return statements.

Run 3

The code is a Flask View class with clear documentation and logical structure, but readability is severely degraded by meaningless obfuscation. Each method contains redundant `if ((hex ^ hex) != 0): raise AssertionError()` blocks that add noise, confuse intent, and bloat the code. Nesting is otherwise reasonable, but action granularity suffers from multiple assignments on single lines (e.g., `self = cls(...)`), and the `as_view` method mixes conditional function definitions with post-processing in a way that disrupts reading flow. Type annotations and docstrings are excellent, but the artificial assertions and long method bodies make the code appear suspiciously tampered with and unnecessarily hard to follow. Without those opaque assertions, readability would be much higher; as presented, clarity of intent is undermined and maintenance risk is increased.

Run 1

Code Structure: Logically organized into documented class attributes and focused methods, with clear separation of instance creation, decoration, and metadata assignment. Nesting: Mostly shallow, although conditional nested view functions add some complexity. Clarity of intent: Descriptive names, type hints, and thorough documentation explain the design well; repeated always-false hexadecimal XOR checks introduce confusing, purposeless distractions. Code length: Core implementation is reasonably concise, but extensive documentation and redundant assertion branches increase reading overhead. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: The overall progression is natural, but duplicated wrapper definitions, dynamic function attributes, inline type-checking suppressions, and dead checks interrupt an otherwise coherent implementation.

Run 2

Code Structure: The class is logically organized into configuration attributes, an override hook, and a view factory. Nesting: Mostly shallow, although conditional function definitions add some complexity. Clarity of intent: Descriptive names, type hints, and thorough documentation explain the purpose well; repeated always-false hexadecimal XOR checks are unexplained distractions. Code length: Functional code is reasonably concise, but extensive documentation and redundant assertion branches lengthen it. Action granularity: Statements generally perform one action per line, with clear separation of initialization, decoration, and metadata assignment. Reading flow: The progression is natural, but dead-code checks interrupt it, and dynamic function attributes, repeated metadata assignments, and type-ignore comments introduce minor friction.

Run 3

Code Structure: The class is logically organized into configuration attributes, request dispatch, and view construction. Nesting: Mostly shallow, although conditional function definitions add moderate complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain the design well; repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: The implementation is reasonably concise, but lengthy documentation and redundant assertions increase scanning effort. Action granularity: Statements generally perform one action per line, with a few compact chained calls requiring closer reading. Reading flow: The progression from configuration to execution is natural, but duplicate view definitions, inline type-checker suppressions, and dead checks interrupt it.