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 not ("methods" not in cls.__dict__):
pass
else:
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 not (meth is None and request.method == "HEAD"):
pass
else:
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 mostly readable with clear intent and good documentation. The class docstring is excellent, explaining purpose with examples. However, there are notable readability issues. The inverted conditional logic in `__init_subclass__` (`if not (...): pass else:`) and `dispatch_request` (`if not (...): pass else:`) is awkward and confusing - it should be simplified to positive conditions without the pass branches. The method names are clear, and the overall structure is logical. Lines are reasonably concise, with one action per line in most cases. The type hints improve clarity, though the `# type: ignore` comments are slightly noisy. Nesting is minimal, which is good. The `for base in cls.__bases__` loop is straightforward. Overall, the code is readable but the unnatural boolean logic patterns reduce clarity significantly.
Run 2
The code is generally readable but has a few awkward patterns that reduce clarity. The class docstring is excellent and clearly explains the purpose. Structure is logical with clear separation of concerns. However, there are two notably unclear conditional patterns using 'if not (condition): pass else:' which inverts normal logic flow - specifically 'if not ("methods" not in cls.__dict__): pass else:' and 'if not (meth is None and request.method == "HEAD"): pass else:'. These double-negative constructions with 'pass' branches make the intent harder to follow than necessary. Both could be rewritten as straightforward positive conditions. The __init_subclass__ method has moderate nesting depth (2-3 levels) which is acceptable. Variable names are clear ('meth', 'methods', 'base', 'key'). The code is concise and each line performs one logical action. Overall the code is readable but those inverted conditionals are unnecessary obstacles to understanding.
Run 3
The code has clear intent and follows a logical structure, but the control flow introduces artificial nesting and inverted conditions. The `if not (...) pass else` blocks in `__init_subclass__` and `dispatch_request` are confusing and reduce readability. These conditions could be simplified to positive, flat forms (e.g., `if "methods" in cls.__dict__:` or `if meth is None and request.method == "HEAD":`). The remaining logic is straightforward, with good use of helper variables and a moderate level of abstraction. Documentation is helpful, but the awkward conditional style and unnecessary indentation make the code harder to follow than necessary. Overall, readable but with notable structural issues.
Run 1
Code Structure: Responsibilities are logically separated into subclass initialization and request dispatch. Nesting: Generally moderate, but negated conditions with empty pass branches add unnecessary nesting. Clarity of intent: The docstring, descriptive method names, and HEAD fallback comment explain the purpose well; double negation obscures otherwise straightforward checks, and View and http_method_funcs are undefined in this excerpt. Code length: Implementation is reasonably concise, although redundant branches add length; 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: Organization is natural, but readers must mentally invert conditions before reaching the meaningful else branches.
Run 2
Code Structure: The class separates method discovery from request dispatch cleanly. Nesting: Mostly shallow, but the inverted conditions with empty pass branches add unnecessary nesting. Clarity of intent: Descriptive method names, documentation, and the HEAD fallback comment explain the purpose well; double negation and abbreviated variables reduce clarity. Code length: The implementation is compact, although pass/else constructs are unnecessarily verbose; the lengthy docstring provides useful context. Action granularity: Statements generally perform one action per line, with only the final handler invocation combining synchronization and execution. Reading flow: Discovery and dispatch follow a logical sequence, but inverted branching interrupts natural reading. Referenced definitions such as View and http_method_funcs are absent from the snippet, slightly limiting self-contained understanding.
Run 3
Code Structure: Responsibilities are logically separated into subclass initialization and request dispatch. Nesting: Mostly moderate, but inverted conditions with empty pass branches add unnecessary nesting. Clarity of intent: Descriptive method names, annotations, a detailed docstring, and the HEAD fallback comment explain the purpose; double negation obscures otherwise simple checks. Code length: Implementation is reasonably concise, although pass/else scaffolding is redundant and the documentation dominates the snippet. Action granularity: Most lines perform one clear action; the final return combines synchronization and invocation but remains understandable. Reading flow: Generally follows a natural sequence, but negative conditions interrupt it. View and http_method_funcs are not defined or imported in the snippet, reducing standalone comprehensibility.