Source code
from __future__ import annotations
import typing as t
from werkzeug.exceptions import BadRequest
from werkzeug.exceptions import HTTPException
from werkzeug.wrappers import Request as RequestBase
from werkzeug.wrappers import Response as ResponseBase
from . import json
from .globals import current_app
from .helpers import _split_blueprint_path
class Response(ResponseBase):
"""The response object that is used by default in Flask. Works like the
response object from Werkzeug but is set to have an HTML mimetype by
default. Quite often you don't have to create this object yourself because
:meth:`~flask.Flask.make_response` will take care of that for you.
If you want to replace the response object used you can subclass this and
set :attr:`~flask.Flask.response_class` to your subclass.
.. versionchanged:: 1.0
JSON support is added to the response, like the request. This is useful
when testing to get the test client response data as JSON.
.. versionchanged:: 1.0
Added :attr:`max_cookie_size`.
"""
default_mimetype: str | None = "text/html"
json_module = json
autocorrect_location_header = False
@property
def max_cookie_size(self) -> int: # type: ignore
"""Read-only view of the :data:`MAX_COOKIE_SIZE` config key.
See :attr:`~werkzeug.wrappers.Response.max_cookie_size` in
Werkzeug's docs.
"""
if current_app:
return current_app.config["MAX_COOKIE_SIZE"] # type: ignore[no-any-return]
# return Werkzeug's default when not in an app context
return super().max_cookie_size
Run 1
The code is highly readable, with clear and logical structure. It imports modules explicitly, defines a response class with a single-focused purpose, and keeps nesting flat. The docstring clearly communicates the class's role and version changes. The `max_cookie_size` property is concise, with a natural reading flow: it first checks the app context, then falls back to the parent class. Variable and method names are descriptive, and type hints are used effectively. The code avoids unnecessary complexity and multiple actions per line, making it easy to follow and maintain.
Run 2
The code is well-structured and highly readable. It uses a clear class hierarchy, logical imports, and meaningful docstrings. The Response class is concise with a clear default mimetype and a well-documented max_cookie_size property. Nesting is minimal, and intent is obvious. The only minor drawbacks are slight verbosity from the docstrings and imports, but these aid maintainability. Action granularity is one per line, and reading flow is natural. Overall, it demonstrates clean, idiomatic Flask extension code.
Run 3
The code is highly readable. It follows a clear logical structure: imports are organized, the class docstring is thorough, and the single method override is concise. Nesting is minimal, with only a simple if-return pattern. Intent is explicit via type hints, descriptive naming, and a detailed docstring. The code is not unnecessarily long—comments and documentation add value. Action granularity is appropriate, with one logical action per line. Reading flow is natural, moving from imports to class definition to method. Minor deductions: the `# type: ignore` comments slightly clutter readability, and the conditional return could arguably be structured differently, but overall it is well-structured and easy to follow.
Run 1
Code Structure: Imports, class defaults, and the property are logically organized with clear separation. Nesting: A single conditional and early return keep the code flat. Clarity of intent: Descriptive names, type annotations, documentation, and the fallback comment clearly explain the Flask-specific response behavior. Code length: Implementation is concise; the lengthy class docstring adds useful context, although version-history details slightly interrupt scanning. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: The progression from imports to class configuration to context-dependent behavior is natural. Minor readability drawbacks include limited spacing between top-level sections and type-ignore annotations that add visual noise.
Run 2
Code Structure: The class is logically organized, with class attributes followed by a focused property, although several imports are unused in this snippet. Nesting: A single conditional keeps the implementation flat and easy to follow. Clarity of intent: Descriptive names, type annotations, documentation, and the fallback comment clearly explain the response defaults and configuration lookup. Code length: Executable code is concise; the lengthy class docstring and version history add some reading overhead. Action granularity: Each statement performs one action, with no compressed or compound operations. Reading flow: The property naturally progresses from application-specific configuration to the inherited default. Minor formatting issues, such as missing blank lines between import groups and before the class, slightly reduce polish.
Run 3
Code Structure: The class cleanly groups response defaults and a configuration-backed property, although several imports are unused in this snippet. Nesting: A single conditional and early return keep the implementation flat. Clarity of intent: Descriptive names, type annotations, docstrings, and the fallback comment clearly explain behavior; inheritance and current_app require some framework knowledge. Code length: The executable code is concise, but historical notes make the class docstring disproportionately long. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Imports, class documentation, defaults, and the property follow a natural sequence. Minor spacing issues around imports and the class, plus type-ignore annotations, slightly reduce polish.