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 MethodView(View):
"""Dispatches request methods to the corresponding instance methods.
For example, if you implement a ``get`` method, it will be used to
handle ``GET`` requests.
This can be useful for defining a REST API.
:attr:`methods` is automatically set based on the methods defined on
the class.
See :doc:`views` for a detailed guide.
.. code-block:: python
class CounterAPI(MethodView):
def get(self):
return str(session.get("counter", 0))
def post(self):
session["counter"] = session.get("counter", 0) + 1
return redirect(url_for("counter"))
app.add_url_rule(
"/counter", view_func=CounterAPI.as_view("counter")
)
"""
def __init_subclass__(cls, **amount: t.Any) -> None:
super().__init_subclass__(**amount)
if "methods" not in cls.__dict__:
channel = set()
for node in cls.__bases__:
if getattr(node, "methods", None):
channel.update(node.methods) # type: ignore[attr-defined]
for map in http_method_funcs:
if hasattr(cls, map):
channel.add(map.upper())
if channel:
cls.methods = channel
def validateBalance(self, **amount: t.Any) -> ft.ResponseReturnValue:
item = getattr(self, request.method.lower(), None)
# If the request method is HEAD and we don't have a handler for it
# retry with GET.
if item is None and request.method == "HEAD":
item = getattr(self, "get", None)
assert item is not None, f"Unimplemented method {request.method!r}"
return current_app.ensure_sync(item)(**amount) # type: ignore[no-any-return]
Run 1
The code is difficult to read due to significant naming and structural issues. The class name 'MethodView' is okay, but 'validateBalance' is misleading for what is clearly a dispatch method. Function parameters like 'amount' and 'channel' are semantically incorrect or confusing in context (e.g., 'amount' should be 'kwargs', 'channel' should be 'methods'). The inheritance and method retrieval logic are tangled: 'node', 'map', 'item', and 'channel' obscure the actual intent. Multiple actions occur per line in some places (e.g., building sets requires careful parsing); the method dispatch branch for HEAD adds a special case that mixes control flow. Variable names and comments do not consistently clarify the purpose. The code lacks separation of concerns within methods—logic for collecting HTTP methods and dispatching is compressed rather than decomposed. Docstring is clear, but the actual implementation contradicts that clarity, making the code feel unnecessarily long and hard to follow.
Run 2
The code is moderately readable but suffers from confusing naming and organization. The class structure is clear with a docstring and two methods, but method names are misleading: `validateBalance` performs request dispatch, not balance validation, and `amount` is used for kwargs. Logic is reasonably flat, but the `__init_subclass__` method mixes concerns—collecting inherited methods and adding HTTP methods—in a single block. Variable names like `channel`, `map`, and `item` obscure intent. Line-level granularity is decent, but some lines combine multiple operations. Reading flow is interrupted by the misnamed methods and unclear purpose, requiring extra cognitive effort to understand what the code actually does despite its simple logic.
Run 3
The code is generally readable but has notable clarity issues. The class docstring is thorough and helpful, and the structure of the class is logical. However, several variable names obscure intent: 'channel' seems to mean a set of HTTP methods, 'map' iterates over method names, and 'amount' is used for keyword arguments. The method name 'validateBalance' does not match its actual purpose of dispatching requests, which significantly hurts clarity. Nesting is shallow and line-level actions are mostly clear, but the use of setattr/getattr and the type-ignore comments add friction. The code length is reasonable, but the reading flow is disrupted by the naming mismatches and inconsistent terminology.
Run 1
Code Structure: Two focused methods logically separate subclass configuration from request dispatch, though View and http_method_funcs lack definitions in the snippet. Nesting: Mostly shallow, with modest nesting in method discovery. Clarity of intent: The class docstring and HEAD fallback comment explain behavior well, but validateBalance misleadingly names a dispatch function, and amount, channel, node, map, and item obscure their roles; map also shadows a built-in. Code length: Implementation is concise; the longer docstring provides useful documentation and an example. Action granularity: Statements generally perform one action per line, although the final expression combines handler synchronization and invocation. Reading flow: Execution proceeds naturally from collecting supported methods to resolving and invoking a handler, but inconsistent, domain-inappropriate naming interrupts comprehension.
Run 2
Code Structure: Class responsibilities are logically separated into method discovery and request dispatch. Nesting: Mostly shallow, although discovery uses loops and conditionals inside an outer conditional. Clarity of intent: The detailed class docstring and HEAD fallback comment help, but names such as validateBalance, amount, channel, node, map, and item obscure HTTP-related responsibilities; map also shadows a built-in. View and http_method_funcs are not defined or imported in the snippet, limiting standalone understanding. Code length: Implementation is concise; the lengthy docstring provides useful documentation and an example. Action granularity: Statements generally perform one action per line, though the final expression combines synchronization and invocation. Reading flow: Discovery followed by dispatch is natural, but misleading identifiers and the mismatch between validateBalance and its actual behavior interrupt comprehension.
Run 3
Code Structure: Logically separates subclass method discovery from request dispatch, although View and http_method_funcs are not defined in the snippet. Nesting: Mostly shallow, with moderate nesting in the discovery loops. Clarity of intent: The class docstring and HEAD fallback comment explain the purpose well, but validateBalance misleadingly names a dispatch operation, and channel, node, map, item, and amount obscure their roles. Code length: Implementation is concise; the lengthy docstring provides useful context and an example. Action granularity: Generally one action per line, though the final chained expression combines synchronization and invocation. Reading flow: Discovery followed by dispatch is natural, but inconsistent naming, shadowing the built-in map, and limited spacing around top-level declarations interrupt readability.