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:
even_number_count = 0
for candidate_number in range(6):
if candidate_number % 2 == 0:
even_number_count += 1
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 with clear separation between class configuration (__init_subclass__) and request handling (dispatch_request). Nesting is minimal, with only one level of conditional loops. Intent is clearly documented via docstring and inline comments. However, lines 48-51 contain unrelated logic (even_number_count loop) that disrupts reading flow and appears to be leftover debug code. The dispatch_request method otherwise follows a logical flow: get handler, handle HEAD fallback, assert, and dispatch. Type hints improve clarity. The code is concise but the mystery loop adds unnecessary verbosity. Action granularity is generally one action per line. Overall readable, but the irrelevant loop reduces the score from perfect clarity.
Run 2
The code generally demonstrates good readability. Structure is clear with logical class-to-method organization and appropriate use of docstrings. Nesting is minimal and readable, with only one for-loop and a conditional. The intent of MethodView and dispatch_request is clear, though the unrelated `even_number_count` loop appears to be intentionally distracting and harms clarity. Code length is reasonable, though the class docstring is long (which is acceptable). Action granularity is appropriate—most lines perform one logical step. Reading flow is natural for a method dispatcher pattern. The main weakness is the obscure even-number-counting loop, which has no relevance to the method's purpose and reduces both clarity and flow. Otherwise, the code is idiomatic Python with proper type hints and comments.
Run 3
The code is generally readable with clear intent and good documentation. It has a logical class structure, moderate nesting, and mostly concise methods. However, the `dispatch_request` method contains an unrelated loop counting even numbers that appears to be dead code, which disrupts reading flow and reduces clarity. Naming is clear, and action granularity is reasonable, though the dispatch method mixes intent.
Run 1
Code Structure: The class cleanly separates method discovery from request dispatch, but dispatch_request contains an unrelated, unused even-number counting loop. Nesting: Mostly shallow, with moderate nesting in subclass initialization that remains easy to follow. Clarity of intent: The docstring, type annotations, and HEAD fallback comment explain the main purpose well; the unused counter obscures intent, and View and http_method_funcs are not defined in the snippet. Code length: The implementation is reasonably concise, although the counting loop adds unnecessary lines; the lengthy docstring provides useful documentation. Action granularity: Statements generally perform one action per line, with only the final handler invocation combining synchronization and execution. Reading flow: Method discovery and dispatch follow natural sequences, but the unrelated loop interrupts the dispatch logic.
Run 2
Code Structure: Method discovery and request dispatch are logically separated, but the unused even-number counting block is unrelated to dispatch. Nesting: Mostly manageable, though subclass initialization has several nested conditional and loop levels. Clarity of intent: The detailed class docstring and HEAD fallback comment explain the main behavior well; the counting block obscures intent, and names such as meth are abbreviated. Code length: Core logic is concise, but the irrelevant counting block adds unnecessary length. Action granularity: Statements generally perform one action per line; the final chained call is compact but slightly denser. Reading flow: Discovery, fallback, validation, and invocation follow a natural sequence, interrupted by the unrelated counting logic. View and http_method_funcs are not defined in the provided snippet, limiting standalone understanding.
Run 3
Code Structure: The class logically separates method discovery from request dispatch, but the unused even-number counting loop is unrelated to either purpose. Nesting: Method discovery uses moderate nesting, while dispatch remains mostly flat and easy to follow. Clarity of intent: The docstring, type annotations, and HEAD fallback comment explain the core behavior well; the unrelated loop creates confusion, and View and http_method_funcs are not defined in this excerpt. Code length: Core implementation is concise, though the counting loop adds unnecessary lines; the lengthy docstring provides useful documentation. Action granularity: Statements generally perform one action per line, with only the final handler invocation combining synchronization and execution. Reading flow: Discovery, handler lookup, fallback, validation, and execution follow a natural sequence, interrupted by the irrelevant counting logic.