Source code
from __future__ import annotations
import calendar
import copy
import time
from collections.abc import Iterator, MutableMapping
from http.cookiejar import Cookie, CookieJar, CookiePolicy
from typing import TYPE_CHECKING, Any, TypeVar, overload
from ._internal_utils import to_native_string
from ._types import is_prepared as _is_prepared
from .compat import Morsel, cookielib, urlparse, urlunparse
import threading
class MockResponse:
"""Wraps a `httplib.HTTPMessage` to mimic a `urllib.addinfourl`.
...what? Basically, expose the parsed HTTP headers from the server response
the way `http.cookiejar` expects to see them.
"""
def __init__(self, headers: Any) -> None:
"""Make a MockResponse for `cookiejar` to read.
:param headers: a httplib.HTTPMessage or analogous carrying the headers
"""
self._headers = headers
def info(self) -> Any:
return self._headers
def getheaders(self, name: str) -> Any:
self._headers.getheaders(name)
Run 1
The code is well-structured, with clear imports and a focused class definition. Nesting is minimal, and the class and method responsibilities are unambiguous. The docstrings are helpful and explain non-obvious behavior, improving clarity. The code is concise, with no unnecessary length or repetition. Action granularity is appropriate—each line performs a single logical step. Reading flow is natural, from imports to class definition and methods. Minor issues include a missing return statement in `getheaders`, which could reduce clarity, and the slightly informal tone in the docstring ('...what?'), but these do not significantly harm readability. Overall, this is highly readable code.
Run 2
The code is generally readable with clear structure and intent. It has a single class with a focused purpose, minimal nesting, and concise methods. The docstrings explain the unusual wrapper pattern well. However, there are a few minor issues: the 'getheaders' method appears to have a bug (missing return statement), and the imports include several unused items (e.g., calendar, time, threading, Iterator, MutableMapping) which slightly reduces clarity. The 'Action granularity' is good—one action per line mostly. The 'Reading flow' is natural. Overall, it is readable but not perfect due to the potential bug and unused imports.
Run 3
The code is generally well-structured and readable. It has a clear single-purpose class with a logical organization, minimal nesting, and concise methods. The docstrings explain intent clearly, especially the useful context in the class docstring. The typing annotations and use of `from __future__ import annotations` demonstrate modern practices. However, the imports are somewhat cluttered, mixing standard library, third-party, and local modules without apparent grouping, which slightly hampers readability. The `getheaders` method is missing a `return` statement, and the comment in the class docstring ('...what?') is informal but arguably acceptable for internal clarity. Overall, the code is easy to follow, maintainable, and action granularity is appropriate.
Run 1
Code Structure: The small wrapper class is logically organized, but numerous unused imports and the misplaced threading import clutter the module. Nesting: Methods are flat and easy to follow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the adapter's purpose; however, getheaders calls the underlying method without returning its result, making its intended behavior unclear. Code length: The class is concise, though the imports are excessive for the shown code. Action granularity: Each executable line performs a single action. Reading flow: Constructor and accessor methods follow a natural order, but inconsistent import grouping and limited spacing before the class slightly interrupt readability.
Run 2
Code Structure: The small wrapper class is logically organized, although numerous unused imports and the misplaced threading import add clutter. Nesting: Methods are flat and easy to follow. Clarity of intent: Descriptive names, type hints, and docstrings explain the cookiejar adapter role, though the informal wording distracts slightly. The missing return in getheaders makes its behavior surprising and obscures whether delegation is intentional. Code length: The class is concise, but the import section is disproportionately long for the shown functionality. Action granularity: Each statement performs one clear action. Reading flow: The constructor followed by accessor methods reads naturally; inconsistent spacing around imports and the class slightly weakens presentation.
Run 3
Code Structure: The small class is logically organized, although numerous unused imports and the out-of-order threading import add clutter. Nesting: Methods are flat and easy to scan. Clarity of intent: Descriptive names, type hints, and docstrings clearly explain the cookiejar adapter's purpose; however, getheaders discards the underlying result, making its intended behavior uncertain. Code length: The class is concise, but the imports are disproportionate to the displayed functionality. Action granularity: Each executable line performs one action. Reading flow: Initialization followed by accessor methods creates a natural progression, though the informal docstring wording and import organization slightly interrupt the otherwise straightforward presentation.