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 well-structured and readable. The class has a clear single responsibility (adapting headers for cookiejar), demonstrated by the docstring that explains the unconventional purpose with a touch of humor. Imports are organized logically with standard library, third-party, and local imports separated. Nesting is flat with only one level of indentation. Naming is descriptive (MockResponse, headers, info, getheaders). Lines are concise with one action per line. The getheaders method has a potential missing return statement, but this is a minor oversight, not a readability issue. Type hints improve clarity. The docstrings follow conventions and clearly explain parameters. Overall, the code is remarkably easy to follow, with clear intent and natural reading progression from imports to class definition to methods.
Run 3
The code imports many modules without clear usage, making intent ambiguous. The class structure is minimal and logical, but the getheaders method lacks a return statement, creating a likely bug and unclear flow. Comments use informal language ('...what?'), reducing professionalism and clarity. While nesting is nonexistent and length is short, the unused imports and missing return harm readability. The reading flow is disjointed due to boilerplate interspersed with casual commentary. Action granularity is fine, but overall clarity suffers from dead imports and incomplete implementation.
Run 1
Code Structure: The class is logically organized into initialization and header-access methods, though numerous unused imports and the out-of-order threading import add clutter. Nesting: There is no unnecessary nesting; all methods are flat and easy to scan. Clarity of intent: The class docstring clearly explains its adapter role, and method names and type hints support understanding. However, broad Any annotations provide limited guidance, and getheaders calls the underlying method without returning its result, making its intended behavior unclear. Code length: The implementation is concise, but the imports are disproportionate to this snippet. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: The class reads naturally from construction to accessors, although import organization and the informal docstring phrasing slightly reduce polish.
Run 2
Code Structure: The class is logically organized into initialization and small header-access methods, but numerous unused imports and inconsistent import grouping add clutter. Nesting: Flat methods with no nested control flow are easy to follow. Clarity of intent: The class and constructor docstrings explain the adapter's purpose, although informal wording, broad Any annotations, and getheaders calling a method without returning its result introduce ambiguity. Code length: The implementation is concise, but the imports are excessive for this snippet. Action granularity: Each executable line performs a single action. Reading flow: The progression from constructor to accessors is natural; import ordering and limited spacing between imports and the class slightly weaken presentation.
Run 3
Code Structure: The small wrapper class is logically organized, but numerous unused imports and the out-of-order threading import add clutter. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the cookiejar adapter's purpose, although the informal opening docstring and broad Any types reduce precision. The missing return in getheaders makes its intended behavior less clear. Code length: The class is concise, but the import section is disproportionately long for the shown functionality. Action granularity: Each statement performs one action, making individual lines easy to follow. Reading flow: Initialization followed by accessor methods is natural; better import grouping and spacing before the class would improve presentation.