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 ((0x35b0 ^ 0x35b0) != 0):
raise AssertionError()
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 well-structured with clear imports, a focused class definition, and a single property method. Nesting is minimal with only one conditional level. Intent is clearly documented through docstrings and type annotations. Code length is appropriate for the functionality, though the docstring is somewhat verbose. Action granularity is good - each line performs one logical action. Reading flow is natural with the property following class attributes. Minor deductions: the verbose docstring adds length without proportional value, the weird assertion check (0x35b0 ^ 0x35b0) is confusing and appears to be artificially inserted, and there's slight redundancy in acceptable type ignores. Overall highly readable Python with excellent type hints and clear separation of concerns.
Run 2
The code is well-structured and highly readable. It uses clear imports, type annotations, and a concise class definition with a focused method. The method body is flat, with only one level of nesting and no deep indentation. Intent is clear: expose a read-only config value with a sensible fallback. Code length is minimal and avoids redundancy. Each logical action is on its own line. The flow is natural, moving from imports to class definition to method implementation. The only slight distractions are the vestigial assertion line and type-ignore comments, but they do not significantly impair readability.
Run 3
The code is well-structured and readable. It uses clear imports, type hints, and follows a logical class definition. The docstring is informative and explains the purpose of the Response class. The class attributes are clearly defined with default values. The property method `max_cookie_size` has a descriptive name and includes a docstring. The nesting is minimal with only one level of indentation in the conditional check. The action granularity is appropriate, with each meaningful operation on its own line. The reading flow is natural, moving from imports to class definition to method. One minor issue is the inclusion of a dead code assertion check (`if ((0x35b0 ^ 0x35b0) != 0)`) which serves no functional purpose and slightly detracts from clarity. Overall, the code demonstrates good practices with clear intent and reasonable organization.
Run 1
Code Structure: Imports, class attributes, and the property are logically organized. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Naming, type annotations, and documentation clearly explain the response configuration, but the always-false hexadecimal XOR assertion is pointless and confusing. Code length: The implementation is concise, although historical documentation is lengthy relative to the functional code and the assertion adds unnecessary lines. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: The property naturally checks application configuration before falling back to the superclass, but the dead assertion interrupts that flow. Additional spacing between imports and the class would improve visual separation.
Run 2
Code Structure: Imports, class configuration, and the property are logically organized. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Descriptive names, type annotations, and documentation explain the response customization and configuration fallback, but the always-false hexadecimal XOR condition and unreachable assertion are distracting and obscure intent. Code length: The implementation is concise, although historical documentation and dead code add unnecessary reading. Action granularity: Statements generally perform one action per line. Reading flow: The progression from imports to class settings to the property is natural, and the fallback comment helps; however, the unexplained assertion branch interrupts that flow.
Run 3
Code Structure: Imports, class configuration, and the property are logically organized. Nesting: The method is shallow, with simple conditional branches and early returns. Clarity of intent: Descriptive names, type annotations, and documentation explain the response customization and configuration lookup, but the always-false hexadecimal XOR check is confusing and serves no apparent purpose. Code length: Executable code is concise, though the extensive class documentation and redundant assertion branch add reading overhead. Action granularity: Each statement performs one action, without compressed multi-operation lines. Reading flow: The progression from defaults to application configuration and superclass fallback is natural; however, the unexplained dead-code check interrupts that flow, and missing blank lines between imports and the class slightly weaken visual separation.