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 generally readable and well-organized. It starts with clear imports (though some may be unused) and defines a single class with a focused responsibility. The class has a clear docstring explaining its purpose, and the methods are concise with appropriate type hints. Nesting is minimal, and the reading flow is natural. However, there is a bug in `getheaders`: it calls `self._headers.getheaders(name)` but does not return the result, which could be misleading. The use of `Any` types reduces clarity of intent slightly, and the variable name `_headers` is somewhat generic. The comments in the docstring ('...what?') are informal but add personality without harming clarity. Overall, the structure is logical, and the code is easy to follow, but the missing return statement and loose typing prevent a higher score.
Run 2
The code is generally clear and well-organized, with a logical class structure, good use of typing, and helpful docstrings that explain a non-obvious purpose. Nesting is minimal, actions are simple, and reading flow is natural. However, the method `getheaders` lacks a `return` statement, which is likely a bug and hurts clarity of intent. Some imports and type annotations add slight verbosity, and the class name 'MockResponse' could be more descriptive. Overall, it is readable but slightly undermined by the missing return and modest complexity.
Run 3
The code has a clear purpose and is structured into a single class with an understandable docstring. Some strengths include logical organization, shallow nesting, and a consistent naming pattern. However, there are several readability issues: the getheaders method is missing a return statement, making the intent unclear and the code incorrect. The constructor docstring is helpful but the class-level docstring includes informal phrasing that reduces professionalism. Imports are reasonable, though some may be unused, which adds noise. Function lengths are concise, but the overall action granularity is acceptable. The reading flow is generally natural, but the incomplete method disrupts clarity and trust in the implementation.
Run 1
Code Structure: The small wrapper class is logically organized, but numerous unused imports and the misplaced threading import add clutter. Nesting: Methods are flat, with no complex branching or deep nesting. Clarity of intent: The class docstring clearly explains its compatibility purpose, and method names are recognizable, though getheaders omitting a return makes its intended behavior uncertain. Code length: The implementation is concise, but the import block is disproportionate to the shown functionality. Action granularity: Each statement performs a single action, making individual lines easy to understand. Reading flow: The class progresses naturally from initialization to header access methods; inconsistent import grouping and limited spacing before the class slightly interrupt the flow.
Run 2
Code Structure: The small wrapper class is logically organized, though numerous unused imports and inconsistent import grouping add clutter. Nesting: Methods are flat and easy to follow, with no complex control flow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the adapter's purpose, but the informal introductory wording is distracting. The missing return in getheaders makes its intended behavior less clear. Code length: The class is concise, although the import section is disproportionate to the functionality shown. Action granularity: Each statement performs a single action. Reading flow: Initialization followed by accessor methods reads naturally; better import organization and spacing before the class would improve presentation.
Run 3
Code Structure: The small class is logically organized, but numerous unused imports and the misplaced threading import add clutter. Nesting: Methods are flat and easy to follow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the HTTP-header adapter well, although the informal docstring wording is distracting. The missing return in getheaders makes its intended behavior less clear. Code length: The class is concise, but the import block is excessive for the shown functionality. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: Methods progress naturally from initialization to header access; inconsistent import grouping and limited spacing before the class slightly weaken the flow.