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 due to its clear structure and concise methods. The __init_subclass__ logic is logically organized, with two separate loops that have distinct responsibilities (inheriting base methods and adding HTTP method handlers). Nesting is minimal, with a flat structure inside the conditionals. Intent is explicit through descriptive variable names (meth, methods) and the docstring example. The code is concise but not overly terse, with each line performing a single logical action. The dispatch_request method follows a natural flow: retrieve handler, handle HEAD fallback, assert validity, and dispatch. Type hints and comments enhance clarity without adding noise. Minor deductions: the type: ignore comments are slightly distracting, and the set update line could be split for perfect one-action-per-line granularity.
Run 3
The code is highly readable with clear structure, minimal nesting, and explicit intent. The MethodView class is well-organized with a descriptive docstring and separated concerns. The __init_subclass__ method uses flat conditionals and loops with clear variable names. dispatch_request is concise, handles the HEAD fallback explicitly, and uses assertion for an invariant. Each line performs a single logical action, and comments add context without noise. Type hints improve clarity. The only minor concern is the type: ignore comments, but they are justified for framework internals.
Run 1
Code Structure: Two focused methods logically separate supported-method discovery from request dispatch. Nesting: Dispatch is flat, while subclass initialization has moderate, manageable nesting. Clarity of intent: The comprehensive docstring and HEAD fallback comment explain behavior well; dynamic attribute lookup and externally defined View and http_method_funcs require some context. Code length: Implementation is concise, with documentation adding useful examples rather than unnecessary complexity. Action granularity: Statements generally perform one action each, though the final return combines synchronous adaptation and handler invocation. Reading flow: Initialization proceeds naturally from inherited methods to implemented handlers, and dispatch follows lookup, fallback, validation, and execution. Minor readability limitations include the abbreviated variable meth and framework-specific typing suppressions.
Run 2
Code Structure: Two well-separated methods organize method discovery and request dispatch logically. Nesting: Subclass initialization has moderate nesting through conditionals and loops, while dispatch remains flat. Clarity of intent: The descriptive docstring, type annotations, and HEAD fallback comment make behavior clear; abbreviated names such as meth and ft are less explicit, and View and http_method_funcs are not defined in the snippet. Code length: Implementation is concise; the lengthy docstring provides useful explanation and an example rather than unnecessary code. Action granularity: Most lines perform one action, though the final return combines handler adaptation and invocation. Reading flow: Initialization proceeds naturally from inherited methods to locally available handlers, and dispatch flows from lookup to fallback, validation, and execution. Additional spacing between imports and the class would improve visual separation.
Run 3
Code Structure: Responsibilities are logically separated between subclass method discovery and request dispatch. Nesting: Discovery uses moderate nesting (conditional, loop, conditional), while dispatch remains flat and easy to follow. Clarity of intent: Descriptive names, type annotations, a thorough docstring, and the HEAD fallback comment explain behavior well. However, View and http_method_funcs are undefined in the provided snippet, requiring external context. Code length: Implementation is concise; the lengthy docstring adds useful documentation and an example rather than redundant code. Action granularity: Statements generally perform one action per line, although the final return combines synchronization and invocation. Reading flow: Imports, class documentation, initialization logic, and dispatch appear in a natural sequence. Dynamic attribute lookup and type-ignore comments introduce minor reading friction.