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, **kwa: t.Any) -> None:
super().__init_subclass__(**kwa)
if "methods" not in cls.__dict__:
met = set()
for bas in cls.__bases__:
if getattr(bas, "methods", None):
met.update(bas.methods) # type: ignore[attr-defined]
for key2 in http_method_funcs:
if hasattr(cls, key2):
met.add(key2.upper())
if met:
cls.methods = met
def dispatch(self, **kwa2: t.Any) -> ft.ResponseReturnValue:
met2 = 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 met2 is None and request.method == "HEAD":
met2 = getattr(self, "get", None)
assert met2 is not None, f"Unimplemented method {request.method!r}"
return current_app.ensure_sync(met2)(**kwa2) # type: ignore[no-any-return]
Run 1
The code is generally well-structured with a clear docstring, helper classes, and minimal nesting. However, readability is reduced by unclear variable names like 'met', 'bas', 'kwa', 'met2', 'kwa2', and 'key2', which obscure intent. Line-level logic is mostly clear, and the control flow is flat (no deep nesting). The docstring is excellent. Overall, it's readable but would benefit from more descriptive variable names and slightly more contextual comments.
Run 2
The code is well-structured with clear class-level organization and separation of concerns. The MethodView class has a logical flow, with __init_subclass__ handling method registration and dispatch handling request routing. Nesting is minimal—loops are shallow and conditionals are simple. Intent is clearly conveyed through descriptive variable names like 'met' for methods and 'bas' for base classes, though these abbreviations slightly reduce clarity. Code length is appropriate without being verbose. Most lines perform a single action, maintaining good granularity. The reading flow is natural: class docstring, method definitions, then implementation details. Minor deductions include abbreviated variable names ('met', 'bas', 'kwa') that could be more explicit, and the type ignore comments add slight noise. Overall, it is highly readable for experienced Python developers, with only minor naming choices preventing a higher score.
Run 3
The code is generally well-structured with clear class and method organization. The docstring provides excellent context and usage examples, improving clarity of intent. Nesting is shallow with only one level in conditionals and loops. However, variable names like 'met', 'bas', 'key2', 'met2', and 'kwa2' are cryptic and reduce readability significantly. The assert statement combines error checking with f-string formatting in a single line, reducing action granularity. The dispatch method logic is concise but could benefit from better variable naming to clarify that 'met2' represents a method handler. The mix of abbreviated and full names creates inconsistency. The type annotations and comments help maintain clarity, but the abbreviated naming pattern detracts from the overall readability despite otherwise clean structure and acceptable length.
Run 1
Code Structure: The class cleanly separates method discovery from request dispatch, although View and http_method_funcs are not defined or imported in the snippet. Nesting: Subclass initialization has moderate nesting, while dispatch remains mostly flat. Clarity of intent: The detailed docstring and HEAD fallback comment explain behavior well, but abbreviated names such as met, bas, kwa, key2, and met2 obscure their roles. Code length: The implementation is concise; the longer docstring provides useful documentation and an example. Action granularity: Most lines perform one action, although the final return combines handler synchronization and invocation. Reading flow: Organization is natural, progressing from documentation to setup and dispatch, but weak variable names and missing context slightly interrupt comprehension.
Run 2
Code Structure: Two focused methods logically separate automatic method discovery from request dispatch. Nesting: Discovery uses moderately nested loops and conditionals, while dispatch remains flat and easy to follow. Clarity of intent: The detailed class docstring and HEAD fallback comment explain behavior well, but abbreviated names such as met, bas, key2, met2, and kwa2 obscure meaning. View and http_method_funcs are not defined or imported in the snippet, reducing standalone clarity. Code length: The implementation is concise; the longer docstring provides useful documentation and an example rather than unnecessary code. Action granularity: Most lines perform one clear action, although the final return combines synchronization wrapping and handler invocation. Reading flow: Discovery proceeds naturally from inherited methods to available handlers, and dispatch follows lookup, fallback, validation, and invocation. More descriptive variable names and clearer dependency context would improve readability.
Run 3
Code Structure: Two focused methods logically separate supported-method discovery from request dispatch. Nesting: Discovery uses moderate nesting with loops and conditionals, while dispatch remains mostly flat. Clarity of intent: The detailed class docstring and HEAD fallback comment explain behavior well, but abbreviated names such as met, met2, bas, kwa, and key2 obscure meaning. View and http_method_funcs are not defined or imported in the snippet, limiting standalone comprehension. Code length: Implementation is concise; the lengthy docstring provides useful documentation and an example rather than unnecessary code. Action granularity: Most lines perform one clear action, although the final return combines handler synchronization and invocation. Reading flow: Discovery proceeds naturally from inherited methods to implemented handlers, and dispatch follows lookup, fallback, validation, and execution. More descriptive identifiers and clearer import completeness would improve readability.