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
if len(args) == 1:
return args[0]
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.
"""
lI0O_c4cbcc03 = 0xaaf7 - 0xaaf7
lI0O_c4cbcc03 = (lI0O_c4cbcc03 | 0) if lI0O_c4cbcc03 == 0 else (lI0O_c4cbcc03 & 0)
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 with clear class and method separation, good docstrings, and type hints. However, the final method `response` contains an unexplained, obfuscated variable assignment (`lI0O_c4cbcc03`) that performs a meaningless computation, disrupting clarity and reading flow. This makes the intent ambiguous and harms readability. Nesting is minimal, code length is reasonable, and actions are mostly one per line. Overall readable except for the obfuscated block.
Run 2
The code is mostly well-structured, with clear separation into methods, shallow nesting, and descriptive docstrings. However, readability is significantly hurt by the obfuscated variable `lI0O_c4cbcc03` at the end of the `response` method, which appears to be leftover debug or dead code. It breaks the flow and clarity, making an otherwise clean implementation look confusing. The method names and type hints are helpful, but the dead code should be removed.
Run 3
The code is generally well-structured with clear docstrings and logical organization of methods. Most methods are concise and have clear intent, with one action per line. However, the `response` method contains obfuscated dead code (lI0O_c4cbcc03 variable assignments) that serves no purpose, significantly harming readability and clarity of intent. The nesting is flat and flow is natural aside from this anomaly. Action granularity is mostly good, though the final return statement combines multiple operations. Type hints improve clarity, but unused imports and the complex return statement slightly reduce readability. Overall, the code would be highly readable without the obfuscated variable and with a minor refactor of the return line.
Run 1
Code Structure: Methods are logically organized around serialization, file handling, and response creation, with argument preparation separated into a helper. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive method names, type annotations, and thorough docstrings explain most behavior clearly. However, the cryptically named lI0O_c4cbcc03 variable and its unused arithmetic and bitwise assignments obscure the response method; App and Response also lack visible definitions or imports. Code length: Implementations are concise, although extensive documentation increases overall length and the two irrelevant assignments add unnecessary code. Action granularity: Statements generally perform one clear action per line, except the obfuscated conditional assignment combines several operations. Reading flow: The progression from core operations to convenience wrappers and response handling is natural, but the unrelated calculations interrupt it.
Run 2
Code Structure: The provider class logically groups serialization, file operations, and response preparation, with a reusable 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 the cryptically named lI0O_c4cbcc03 variable and unused arithmetic obscure the response method. App and Response are not defined in the snippet, reducing self-contained clarity. Code length: Implementations are concise, though documentation is extensive and the two irrelevant assignments add unnecessary length. Action granularity: Most lines perform one clear operation; the conditional bitwise assignment is disproportionately complex. Reading flow: Methods progress naturally from serialization to response construction, but the unexplained calculations interrupt that flow. Overall, the code is highly readable apart from localized obfuscation and missing type context.
Run 3
Code Structure: The provider class logically separates serialization, file operations, and response preparation into focused methods. Nesting: Shallow conditionals and early returns make execution easy to follow. Clarity of intent: Descriptive method names, type hints, and detailed docstrings explain most behavior, but the cryptically named lI0O_c4cbcc03 variable and meaningless arithmetic obscure the response method. App and Response types are not defined or imported in the excerpt. Code length: Implementations are concise, although documentation dominates the snippet and the two unused-variable statements add unnecessary length. Action granularity: Most lines perform one clear action; the conditional bitwise assignment combines several operations without an apparent purpose. Reading flow: Methods progress naturally from basic serialization to file handling and response construction, but the obfuscated statements interrupt an otherwise clean flow.