Sample

pyint-ebc9a7c1a5fd-I05

Rewrite eligible decimal integer literals in hexadecimal notation

Matched original source

Lines126

Scores

MethodScoreScale
Posnett0.0020–1; higher is more readable
Dorn0.4590–1; higher is more readable
Mi0.4640–1; higher is more readable
LLOC35Logical lines; fewer is more readable
DeepSeek V4 Pro170–20; mean of three runs
GPT-6.1 Sol180–20; mean of three runs
BTTF0.6530–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.126+50.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.517−6.775

Intercept 8.87 + feature contributions = -6.165 (log-odds).
Score = sigmoid(-6.165) = 0.002.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.127−3.46
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.125.856+1.349
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.110−0.994
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.976+0.97
Indentation frequencyHow rapidly indentation changes from line to line.46+0.854
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.03+0.649
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = -0.164 (log-odds).
Score = sigmoid(-0.164) = 0.459.

Score0.464
Score35
Run 1

The code is highly readable due to its clear class-based structure, comprehensive docstrings, and logical organization. The View class is well-documented with examples and version notes, making intent explicit. Function definitions are straightforward, and type hints improve clarity. Nesting is minimal—only one level in the as_view method's conditional blocks. The code is moderately concise, with some verbose type ignores and long lines that slightly reduce readability. Action granularity is generally good, though a few lines combine multiple operations (e.g., function calls with type ignores). Overall reading flow is natural, progressing logically from class attributes to methods. Minor deductions for occasional line length and type-ignore clutter.

Run 2

The code is well-structured with clear class and method organization, type hints, and descriptive docstrings. The nesting is shallow, primarily using one conditional branch in as_view. Intent is clear, especially with explanatory comments. Length is reasonable given the need for detailed documentation. Action granularity is mostly one action per line, though a few lines combine multiple operations (e.g., self assignment inside view function, type ignores). Reading flow is logical: class docstring, class-level attributes, dispatch_request, then as_view. Minor readability issues include inline type ignores, a nested function with internal comment clutter, and the repeated view metadata setup at the end. Overall highly readable.

Run 3

The code is generally clear and well-organized. The View class has a logical structure with class-level attributes documented and methods separated by purpose. Docstrings are thorough and provide helpful context. Nesting is shallow, with only one level inside the as_view method. The action granularity is mostly appropriate—each line performs a single operation, though a few lines (e.g., calling ensure_sync and dispatch_request together) combine multiple actions. Reading flow is natural due to consistent formatting and documentation. The main deductions come from slightly dense type annotations and long lines in the as_view method that could be split for clarity, along with some repetitive logic between the two branches of the init_every_request conditional. Overall, the code is readable but could be marginally improved by extracting the branching logic into a helper method or simplifying the view function creation.

Run 1

Code Structure: Logically organized into configuration attributes, an override hook, and a view factory. Nesting: Moderate and purposeful; conditional nested functions and a decorator loop remain easy to follow. Clarity of intent: Descriptive names, type annotations, and detailed documentation clearly explain behavior, including instance reuse and attached metadata. Dynamic function attributes and repeated type-ignore comments add some complexity. Code length: Implementation is concise, though extensive documentation and duplicated dispatch calls increase reading length. Action granularity: Each statement generally performs one action; chained ensure_sync invocation is compact but slightly denser. Reading flow: Natural progression from configuration to construction, decoration, and metadata assignment, with minor friction from defining view separately in each branch.

Run 2

Code Structure: Imports, configuration attributes, and methods are logically organized with clear responsibilities. Nesting: Limited to straightforward conditionals, nested view functions, and a decorator loop; depth remains manageable. Clarity of intent: Descriptive names, type annotations, and thorough documentation explain instance lifecycle, dispatch, and decorator behavior. Dynamic function attributes and closure-based instantiation require some extra attention. Code length: Executable code is concise, although extensive documentation and duplicated dispatch wrappers make the snippet longer to scan. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Progresses naturally from configuration to dispatch and view generation; inline type-ignore annotations and repeated metadata assignments slightly interrupt the flow.

Run 3

Code Structure: Imports, class configuration, dispatch contract, and view factory are logically organized. Nesting: Mostly shallow; conditional nested functions and the decorator loop add modest complexity. Clarity of intent: Descriptive names, type annotations, and thorough documentation clearly explain lifecycle choices and metadata handling, although dynamic function attributes and type-ignore comments require extra interpretation. Code length: Executable code is concise, but extensive documentation and duplicated dispatch wrappers increase scanning effort. Action granularity: Statements generally perform one action per line; chained synchronization and dispatch calls are slightly denser. Reading flow: Progression from configuration to implementation is natural, with clear branches and explanatory comments. Minor distractions include long lines, repeated metadata assignments, and defining the same closure name in separate branches.