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, **kwargs: t.Any) -> None:
super().__init_subclass__(**kwargs)
if "methods" not in cls.__dict__:
methods = set()
for base in cls.__bases__:
if getattr(base, "methods", None):
methods.update(base.methods) # type: ignore[attr-defined]
for key in http_method_funcs:
if hasattr(cls, key):
methods.add(key.upper())
if methods:
cls.methods = methods
def dispatch_request(self, **kwargs: t.Any) -> ft.ResponseReturnValue:
meth = 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 meth is None and request.method == "HEAD":
meth = getattr(self, "get", None)
assert meth is not None, f"Unimplemented method {request.method!r}"
return current_app.ensure_sync(meth)(**kwargs) # type: ignore[no-any-return]
Run 1
The code is well-structured and readable. The MethodView class has a clear purpose, with a helpful docstring and example. __init_subclass__ is logically organized, using an early check to avoid unnecessary work, followed by two clear collection phases (base classes and HTTP methods). Nesting is moderate: the 'if methods not in cls.__dict__' block contains nested loops, but the logic remains followable. Variable names like 'meth' and 'methods' are concise but contextually clear. Action granularity is appropriate—each line performs a distinct operation, and the conditional HEAD fallback is commented for clarity. The dispatch_request method is flat and direct, with a precise assertion message. Minor readability costs include the type: ignore comments and the somewhat terse 'meth' name, but these are consistent with the surrounding Flask codebase style. Overall, the code balances conciseness with clarity effectively.
Run 2
The code is highly readable. It has a clear class structure with a well-documented purpose, including a helpful usage example. The `__init_subclass__` method is logically organized, with clear intent and a flat control flow that avoids excessive nesting. The `dispatch_request` method is concise, with each action on its own line and a clear fallback mechanism for HEAD requests. Variable names like `meth` and `methods` are slightly abbreviated but still clear in context. Type hints and comments enhance clarity without adding noise. The only minor deduction is that the `__init_subclass__` loop could be slightly more explicit, but overall the code is excellent in terms of readability.
Run 3
The code is highly readable. It has a clear class structure with a descriptive docstring and well-separated methods. Nesting is minimal, limited to two 'if' blocks and two loops in __init_subclass__, keeping the logic flat and easy to follow. Intent is unambiguous: the methods dynamically map HTTP verbs to class methods. The code is concise, avoiding redundant comments or excessive abstraction. Most lines perform a single logical action, such as method retrieval or attribute assignment. Reading flow is natural, with a logical sequence: class definition, subclass initialization, then dispatch logic. The inline 'type: ignore' comments slightly interrupt visual flow but are minor. Overall, this demonstrates clean, maintainable code that balances clarity with brevity.
Run 1
Code Structure: Logically separates automatic method discovery from request dispatch. Nesting: Mostly shallow, although subclass initialization has moderate nesting through loops and conditionals. Clarity of intent: The descriptive docstring, type annotations, and HEAD fallback comment explain behavior well; abbreviated names such as 'meth' and external definitions such as 'View' and 'http_method_funcs' require some context. Code length: Implementation is concise, and the longer docstring provides useful documentation rather than unnecessary verbosity. Action granularity: Each line generally performs one clear action, though the final return combines handler adaptation and invocation. Reading flow: Method discovery proceeds naturally from inherited handlers to class handlers, while dispatch follows a straightforward lookup, fallback, validation, and invocation sequence.
Run 2
Code Structure: The class cleanly separates HTTP method discovery from request dispatch. Nesting: Subclass initialization has moderate nesting through conditionals and loops, while dispatch remains flat. Clarity of intent: Descriptive method names, type annotations, the detailed docstring, and the HEAD fallback comment explain behavior well; abbreviated names such as meth and external definitions such as View and http_method_funcs slightly reduce standalone clarity. Code length: The implementation is concise, although the documentation occupies much of the snippet. Action granularity: Each statement generally performs one action; the final chained call is compact but still understandable. Reading flow: Initialization precedes dispatch naturally, with whitespace separating logical steps. Missing definitions in the excerpt and type-ignore annotations introduce minor reading friction.
Run 3
Code Structure: The class cleanly separates automatic method registration from request dispatch. Nesting: Registration has moderate nesting through a condition, loops, and inner checks; dispatch remains flat. Clarity of intent: The descriptive docstring, method names, and HEAD fallback comment explain the behavior well, although the abbreviated name 'meth' and externally defined View and http_method_funcs require context. Code length: Implementation is concise; the longer docstring provides useful documentation and an example rather than unnecessary logic. Action granularity: Statements generally perform one action per line, with only the final chained call combining synchronization and invocation. Reading flow: Execution proceeds naturally from collecting supported methods to selecting and invoking a handler. Additional spacing between imports and the class would improve visual separation.