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 highly readable. It follows a clear logical structure with a single class definition and a well-documented purpose. Imports are organized and the docstring provides necessary context. Nesting is minimal, with only one conditional block in the property method. Intent is evident: this is Flask's default Response class with a custom `max_cookie_size` property that respects app config. Code length is concise for its purpose. Each line generally performs one action, enhancing clarity. The reading flow is natural—imports, class docstring, attributes, and methods in expected order. Minor deductions: the `# type: ignore` comments slightly interrupt flow, and the conditional could be simplified, but overall it is excellent.
Run 3
The code is well-structured and highly readable. It uses clear class inheritance, sensible imports, and appropriate type hints. The docstring provides useful context and version notes, enhancing clarity of intent. The class has a logical organization with a default mimetype, JSON module reference, and a single property method. Nesting is minimal—the property contains only one conditional, and the action granularity is appropriate, with one meaningful operation per line. The reading flow is natural: imports, class definition, attributes, then the property. The method name and config access are explicit. Minor deductions include the type-ignore comments, which slightly reduce cleanliness, and the conditional property returns could be marginally simplified, but overall this is concise, maintainable, and follows Flask/Werkzeug conventions well.
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 method flat. Clarity of intent: Descriptive names, type annotations, documentation, and a fallback comment clearly explain the Flask-specific behavior. Code length: Executable code is concise; the lengthy class docstring provides useful context, although version-history details slightly interrupt readability. Action granularity: Each statement performs one action, with no compressed expressions or compound statements. Reading flow: The code progresses naturally from dependencies to configuration and behavior. Minor drawbacks include minimal spacing between import groups and reliance on framework knowledge to understand current_app's truthiness and type-ignore annotations.
Run 2
Code Structure: The class cleanly groups response defaults and a configuration-backed property, though 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 make the behavior clear; framework-specific context and type-ignore comments add minor friction. Code length: The executable code is concise, although the historical documentation is lengthy relative to the implementation. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: The progression from imports to class documentation, defaults, and property implementation is natural, but missing blank lines between import groups and before the class slightly reduce visual organization.
Run 3
Code Structure: A well-organized Response subclass groups defaults and a single related property logically, although several imports are unused in this snippet. Nesting: Minimal nesting, with one conditional and a straightforward fallback. Clarity of intent: Descriptive names, type annotations, documentation, and the fallback comment clearly explain the configuration-dependent behavior. Code length: The implementation is concise, though the lengthy class docstring and historical notes add reading overhead. Action granularity: Each statement performs one clear action; there are no compressed multi-action lines. Reading flow: Imports, class documentation, defaults, and property implementation follow a natural sequence. Minor formatting issues, such as missing blank lines between imports and the class, and type-ignore comments slightly reduce polish.