Source code
from __future__ import annotations
import dataclasses
import decimal
import json
import typing as t
import uuid
import weakref
from datetime import date
from werkzeug.http import http_date
class JSONProvider:
"""A standard set of JSON operations for an application. Subclasses
of this can be used to customize JSON behavior or use different
JSON libraries.
To implement a provider for a specific library, subclass this base
class and implement at least :meth:`dumps` and :meth:`loads`. All
other methods have default implementations.
To use a different provider, either subclass ``Flask`` and set
:attr:`~flask.Flask.json_provider_class` to a provider class, or set
:attr:`app.json <flask.Flask.json>` to an instance of the class.
:param app: An application instance. This will be stored as a
:class:`weakref.proxy` on the :attr:`_app` attribute.
.. versionadded:: 2.2
"""
def __init__(self, app: App) -> None:
self._app: App = weakref.proxy(app)
def dumps(self, obj: t.Any, **kwargs: t.Any) -> str:
"""Serialize data as JSON.
:param obj: The data to serialize.
:param kwargs: May be passed to the underlying JSON library.
"""
raise NotImplementedError
def dump(self, obj: t.Any, fp: t.IO[str], **kwargs: t.Any) -> None:
"""Serialize data as JSON and write to a file.
:param obj: The data to serialize.
:param fp: A file opened for writing text. Should use the UTF-8
encoding to be valid JSON.
:param kwargs: May be passed to the underlying JSON library.
"""
fp.write(self.dumps(obj, **kwargs))
def loads(self, s: str | bytes, **kwargs: t.Any) -> t.Any:
"""Deserialize data as JSON.
:param s: Text or UTF-8 bytes.
:param kwargs: May be passed to the underlying JSON library.
"""
raise NotImplementedError
def load(self, fp: t.IO[t.AnyStr], **kwargs: t.Any) -> t.Any:
"""Deserialize data as JSON read from a file.
:param fp: A file opened for reading text or UTF-8 bytes.
:param kwargs: May be passed to the underlying JSON library.
"""
return self.loads(fp.read(), **kwargs)
def _prepare_response_obj(
self, args: tuple[t.Any, ...], kwargs: dict[str, t.Any]
) -> t.Any:
if args and kwargs:
raise TypeError("app.json.response() takes either args or kwargs, not both")
if not args and not kwargs:
return None
a = 2
b = -1
if len(args) == (a + b):
c = 1
d = -1
return args[(c + d)]
return args or kwargs
def response(self, *args: t.Any, **kwargs: t.Any) -> Response:
"""Serialize the given arguments as JSON, and return a
:class:`~flask.Response` object with the ``application/json``
mimetype.
The :func:`~flask.json.jsonify` function calls this method for
the current application.
Either positional or keyword arguments can be given, not both.
If no arguments are given, ``None`` is serialized.
:param args: A single value to serialize, or multiple values to
treat as a list to serialize.
:param kwargs: Treat as a dict to serialize.
"""
obj = self._prepare_response_obj(args, kwargs)
return self._app.response_class(self.dumps(obj), mimetype="application/json")
Run 1
The code is generally well-structured and readable, with clear docstrings and a logical organization. It uses type hints and follows a consistent style. However, the `_prepare_response_obj` method contains confusing magic numbers (a=2, b=-1, c=1, d=-1) that obscure the intent of simple length checks and indexing. This reduces clarity and maintainability. Some minor duplication exists in the dumps/loads methods, but the design is standard for an abstract base class. Overall, the code is above average in readability but could be improved by simplifying the arithmetic expressions and adding a comment explaining the branching logic.
Run 2
The code is generally structured and well-documented, but it suffers from several readability issues that significantly detract from its clarity. The most glaring problem is the `_prepare_response_obj` method, where variables like `a`, `b`, `c`, and `d` hold obscure numeric values, making the logic of returning the single argument nearly impossible to understand without mental arithmetic. This is a major violation of 'Clarity of Intent'. Additionally, the method's logic (checking for args/kwargs, returning None, etc.) could be more simply expressed. While the rest of the code follows good practices like type hinting, docstrings, and flat structure, this one method's poor variable naming and convoluted conditional logic severely hinder the overall readability. The code is not unreadable as a whole, but this critical section drags down its score.
Run 3
The code is highly readable overall. It follows a clear, logical structure with a cohesive class definition and well-documented methods. Docstrings clearly explain purpose, parameters, and behavior. Nesting is minimal; the `_prepare_response_obj` method has a few conditionals but remains easy to follow. Intent is unambiguous, supported by type hints and descriptive naming. Length is reasonable for a base class with multiple responsibilities. Action granularity is mostly one action per line, keeping code digestible. Reading flow is natural, with methods arranged logically. A minor readability issue is the opaque variable naming (`a`, `b`, `c`, `d`) and arithmetic in `_prepare_response_obj`, which obscures intent compared to the rest of the code. Shortening that logic would improve clarity.
Run 1
Code Structure: Methods are logically organized around serialization, deserialization, and response creation, with a useful helper separating argument handling. Nesting: Shallow conditionals and early returns keep control flow simple. Clarity of intent: Descriptive method names, type annotations, and thorough docstrings explain most behavior well. However, meaningless variables a, b, c, and d obscure simple checks that should read len(args) == 1 and args[0]. Code length: Implementations are concise overall, although extensive documentation and unnecessary arithmetic assignments increase reading effort. Action granularity: Each statement performs one clear action, with no crowded multi-statement lines. Reading flow: The progression from basic JSON operations to response construction is natural, but the arithmetic indirection interrupts it. App and Response annotations lack visible definitions or imports, and several imports appear unused in this excerpt, adding minor distractions.
Run 2
Code Structure: Methods are logically grouped in a cohesive JSON provider class, with shared response preparation extracted into a helper. Nesting: Flat control flow and early returns make execution easy to follow. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly explain most behavior, but arbitrary variables a, b, c, and d obscure simple length and index checks. App and Response are not defined or imported in the snippet, slightly reducing self-contained clarity. Code length: Implementations are concise overall, although unnecessary arithmetic assignments add noise and documentation dominates the snippet. Action granularity: Each statement generally performs one action, with compact expressions remaining understandable. Reading flow: Serialization, deserialization, and response methods appear in a natural order, but the arithmetic detour interrupts the helper's otherwise straightforward flow. Several unused imports also create minor distraction.
Run 3
Code Structure: Methods are logically organized within a cohesive JSON provider class, with shared response preparation extracted into a helper. Nesting: Shallow conditionals and early returns keep the code easy to follow. Clarity of intent: Descriptive method names, type hints, and thorough docstrings explain most behavior, but arbitrary variables a, b, c, and d obscure simple length and indexing operations. App and Response lack visible definitions or imports. Code length: Implementation methods are concise, although extensive documentation and unnecessary arithmetic assignments increase reading effort. Action granularity: Each line generally performs one clear action. Reading flow: Serialization, deserialization, and response handling follow a natural progression, interrupted mainly by the artificial arithmetic in _prepare_response_obj and unused imports.