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 with clear logical organization. The MethodView class has a concise docstring with a helpful example. The __init_subclass__ method is well-structured: it checks for 'methods', collects inherited methods, adds HTTP method names, and assigns if non-empty. Nesting is minimal and flat. Intent is clear at each step. Action granularity is good—one logical action per line. The dispatch_request method follows a natural flow: retrieve handler, handle HEAD fallback, assert validity, and execute. Variable names like 'meth' and 'methods' are intuitive in context. Comments are concise and clarify edge cases without redundancy. Overall, the code balances conciseness with explicitness, making it easy to follow and maintain.
Run 3
The code is well-structured and readable. It has a clear class hierarchy and logical organization. The nesting in __init_subclass__ is shallow (two levels max) and manageable. The purpose is immediately clear from the docstring and method names. The code is concise without being terse, with appropriate use of helper constants and type hints. Most lines perform a single action, and the reading flow follows a natural top-to-bottom progression. The dispatch_request method is particularly clean, with clear comments explaining edge cases. The main minor deductions are the slightly complex logic in __init_subclass__ for combining HTTP methods and the reliance on a global request object, which slightly obscures data flow. Overall, this is exemplary Flask-style code that balances brevity with clarity.
Run 1
Code Structure: Two focused methods cleanly separate supported-method discovery from request dispatch. Nesting: Dispatch is flat; subclass initialization has moderate, manageable nesting through loops and conditionals. Clarity of intent: The detailed docstring, type annotations, and HEAD fallback comment explain behavior well, although 'meth' is abbreviated and View and http_method_funcs are not defined or imported in the snippet. Code length: Implementation is concise; the longer docstring provides useful context and an example rather than unnecessary repetition. Action granularity: Most lines perform one clear action, though the final return combines synchronization and invocation. Reading flow: Initialization proceeds logically from inherited methods to discovered handlers, while dispatch follows lookup, fallback, validation, and execution. Missing spacing between imports and the class slightly weakens presentation.
Run 2
Code Structure: The class cleanly separates method discovery from request dispatch. Nesting: Dispatch is flat, but subclass initialization contains moderately nested conditionals and loops. Clarity of intent: The docstring, type annotations, and HEAD fallback comment explain behavior well; abbreviated names such as 'meth' and external definitions of View and http_method_funcs slightly reduce standalone clarity. Code length: Implementation is concise, while the longer docstring provides useful examples rather than redundant explanation. Action granularity: Most lines perform one clear action; the final return combines synchronization and invocation but remains understandable. Reading flow: Imports, class documentation, initialization, and dispatch follow a logical order, although additional spacing between imports and the class would improve visual separation.
Run 3
Code Structure: Responsibilities are cleanly divided between method discovery and request dispatch. Nesting: Discovery uses moderate nesting, but dispatch remains flat and easy to follow. Clarity of intent: The docstring, type hints, and 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: Implementation is concise, with a longer but useful documentation example. Action granularity: Statements generally perform one action per line, although the final return combines synchronization and invocation. Reading flow: Imports, class documentation, subclass initialization, and dispatch follow a natural order, with whitespace separating logical steps.