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 well-structured and readable. It uses clear class and method names, maintains a flat structure with minimal nesting, and has concise comments explaining non-obvious behavior (HEAD fallback). The dispatch_request method follows a logical flow: retrieve handler, handle edge case, assert, and dispatch. The __init_subclass__ method is slightly more complex due to the loop and conditional logic, but remains understandable. Type hints and docstrings improve clarity. The code is concise without sacrificing readability, and each line performs a single action. Overall, it adheres to good practices for maintainable and readable code.
Run 3
The code is highly readable with clear structure and documentation. The MethodView class serves a single purpose and the __init_subclass__ method logically organizes method detection through two sequential loops with clear intent. Nesting is minimal—only one level deep in the loops and conditional blocks. Action granularity is appropriate, with one distinct operation per line. The docstring provides excellent context with a practical example, though it's somewhat lengthy. The dispatch_request method has clear flow: retrieve method, handle HEAD fallback, assert existence, and dispatch. Type hints and comments add clarity. Minor deductions: the type ignore comments add slight noise, and the methods update loop could potentially be simplified, but overall the code demonstrates exemplary readability with natural reading flow from method resolution to request handling.
Run 1
Code Structure: Two focused methods cleanly separate supported-method discovery from request dispatch. Nesting: Dispatch is flat, while subclass initialization uses moderate, manageable nesting. Clarity of intent: The class docstring, HEAD fallback comment, and descriptive method names explain behavior well; 'meth' is slightly abbreviated, and View and http_method_funcs are not defined in the snippet. Code length: Implementation is concise; the longer docstring provides useful context and an example. Action granularity: Most lines perform one action, although the final return combines synchronization and invocation. Reading flow: Execution follows a natural progression from initialization to handler selection, fallback, validation, and invocation, with whitespace separating logical steps.
Run 2
Code Structure: Two focused methods cleanly separate handler discovery from request dispatch. Nesting: Subclass initialization has moderate nesting through conditions and loops, while dispatch remains flat. Clarity of intent: The descriptive docstring, type annotations, and HEAD fallback comment explain behavior well; abbreviated names such as 'meth' and 'ft', and externally defined View and http_method_funcs, slightly reduce standalone clarity. Code length: Implementation is concise; the lengthy docstring provides useful documentation and an example rather than redundant logic. Action granularity: Each line generally performs one clear action, although the final chained call combines synchronization and invocation. Reading flow: Initialization proceeds naturally from inherited methods to discovered handlers, and dispatch flows clearly from lookup through fallback, validation, and execution.
Run 3
Code Structure: Two focused methods logically separate HTTP-method discovery from request dispatch. Nesting: Discovery has moderate nesting through a conditional, loops, and inner checks; dispatch remains flat. Clarity of intent: The descriptive docstring, type annotations, and HEAD fallback comment explain behavior well, although View and http_method_funcs are undefined in the provided snippet, and meth is an abbreviated name. Code length: Implementation is concise; the lengthy docstring provides useful context rather than redundant detail. Action granularity: Each statement performs a clear action, with only the final chained call combining handler adaptation and invocation. Reading flow: Discovery proceeds naturally from inherited methods to implemented handlers, and dispatch follows lookup, fallback, validation, and execution. Minor spacing improvements between imports and the class would improve presentation.