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 with a clear class structure and logical organization. It uses flat nesting with minimal indentation, making it easy to follow. The intent is explicit through descriptive naming and comprehensive docstrings that explain the class purpose and version changes. Code length is concise for the functionality provided, avoiding unnecessary verbosity. Action granularity is appropriate, with each statement on its own line. Reading flow is natural, starting with imports, then class definition, attributes, and methods. The property method is straightforward with a clear conditional and early return, avoiding nesting. Type hints improve clarity. Overall, the code follows idiomatic Python and Flask conventions, maintaining high readability with only minor complexity from type ignore comments.
Run 3
The code is well-structured and highly readable. It follows clear logical organization with imports at the top, a single class definition, and a docstring explaining the class purpose. Nesting is minimal, with only one level inside the property method. Intent is clear: this defines a Flask Response class with HTML defaults and a read-only max_cookie_size property. Code length is concise and appropriate—no unnecessary verbosity. Action granularity is excellent, with one logical action per line. Reading flow is natural: class definition, docstring, attributes, then the property method. Small improvements could include adding a return type annotation to the property, but overall this is exemplary readable code.
Run 1
Code Structure: Imports, class configuration, and the property are logically organized. Nesting: A single conditional keeps the implementation shallow and easy to follow. Clarity of intent: Descriptive names, type annotations, docstrings, and the fallback comment clearly explain the response customization and configuration lookup. Code length: Executable code is concise, although the lengthy class docstring and version-history notes slightly slow scanning. Action granularity: Each statement performs one action, with no compound lines. Reading flow: The progression from imports to defaults to context-dependent behavior is natural; the early return makes the fallback clear. Minor readability drawbacks include limited spacing between import groups and documentation that outweighs the implementation.
Run 2
Code Structure: The Response subclass clearly groups default settings and a configuration-backed property, although several imports are unused in this snippet. Nesting: A single conditional keeps nesting minimal. Clarity of intent: Descriptive names, type annotations, docstrings, and the fallback comment clearly explain behavior; inherited functionality requires some Werkzeug context. Code length: Implementation is concise, but extensive documentation and version-history notes outweigh the executable code. Action granularity: Each statement performs one action, with no compressed or compound operations. Reading flow: Imports, class documentation, attributes, and property implementation follow a natural sequence. Limited spacing between import groups and the class slightly reduces visual organization.
Run 3
Code Structure: A logically organized response subclass separates class defaults from a single property, although several imports are unused in this snippet. Nesting: Minimal nesting, with one conditional and an early return. Clarity of intent: Descriptive names, type annotations, docstrings, and a fallback comment clearly explain behavior; inherited framework details require some external knowledge. Code length: The implementation is concise, but the lengthy class documentation and version-history notes outweigh the executable code. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: Imports, documentation, defaults, and property implementation follow a natural order. Minor spacing improvements between imports and the class would enhance visual separation.