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 good structure, clear naming, and concise methods. It has a single class with well-defined purpose and flat nesting. The docstrings are helpful. However, there are minor issues: the getheaders method lacks a return statement, and the unused imports (calendar, time, Cookie, CookieJar, CookiePolicy, etc.) reduce clarity. The class name 'MockResponse' is clear, but the docstring uses informal language which lowers professionalism slightly. Overall the code is well-organized but not flawless.
Run 3
The code is generally readable with clear class and method definitions, good docstrings, and a logical structure. Imports are organized, and type hints improve clarity. However, the `getheaders` method lacks a return statement, which could indicate a bug or incomplete implementation and reduces clarity. The class is small and flat, making it easy to follow. Naming is descriptive, and the code is concise without unnecessary verbosity. The overall flow is natural, though the unexplained `MockResponse` context may require reader familiarity with `cookiejar`. Minor issues, such as missing return value and slightly ambiguous class purpose, prevent a higher score.
Run 1
Code Structure: The small wrapper class is logically organized, but numerous unused imports and the misplaced threading import clutter the setup. Nesting: Methods are flat and easy to follow. Clarity of intent: The class docstring explains its compatibility purpose, and method names are recognizable; however, getheaders calls the underlying method without returning its result, making its intended behavior unclear. Code length: The class is concise, though the import list is disproportionate to the functionality shown. Action granularity: Each executable line performs a single action. Reading flow: Constructor and accessor methods appear in a natural order, but informal docstring wording and inconsistent import grouping slightly interrupt the flow.
Run 2
Code Structure: The small wrapper class is logically organized, though numerous unused imports and the late threading import add clutter. Nesting: Methods are flat and easy to scan. Clarity of intent: The class docstring clearly explains its adapter role, and method names are familiar; however, broad Any annotations provide little detail, and getheaders calls the underlying method without returning its result, making its intended behavior unclear. Code length: The class is concise, but the import block is disproportionately large for this snippet. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: Construction followed by header-access methods is natural, although inconsistent import grouping and the informal opening docstring slightly reduce polish.
Run 3
Code Structure: The class is logically organized, with initialization followed by simple access methods, but numerous unused imports clutter this snippet and threading is placed after local imports. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the adapter's purpose, though Any provides little type detail and getheaders omits a return, making its intended behavior unclear. Code length: The implementation is concise, but the import list is disproportionate to the code shown. Action granularity: Each statement performs one clear action. Reading flow: The class reads naturally from its purpose to its methods; inconsistent import grouping and limited spacing before the class slightly weaken presentation.