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 clear and well-structured. It has a logical organization with imports grouped at the top, a class definition, and a docstring explaining a non-obvious design choice. Nesting is minimal, and the reading flow is natural. The class has a single responsibility and the methods are short. However, the `getheaders` method appears to be missing a `return` statement, which reduces clarity of intent. Additionally, the `MockResponse` docstring contains informal language ('...what?') that, while explanatory, may not fit all style guidelines. Overall, readability is good but could be improved with a return value and slightly more formal documentation.
Run 2
The code has a clear structure with a single class and docstrings explaining intent, which helps readability. However, the constructor is straightforward while the getheaders method fails to return the result, which is ambiguous and could confuse readers. Imports are reasonably organized, though some appear unused or excessive for the snippet. The nesting is flat and action granularity is good, with one action per line inside methods. Reading flow is mostly natural, but the missing return statement breaks clarity. Compared to tangled code, this is quite readable, but minor flaws like the unused imports and the silent no-op method reduce the score.
Run 3
The code is reasonably readable with a clear purpose (MockResponse wrapper) and mostly flat structure. Imports are grouped logically, and type hints suggest modern Python. The class has a concise docstring and two simple methods with clear names. However, there are minor issues: the getheaders method is missing a return statement, making its intent slightly ambiguous. The docstring is somewhat conversational ('...what?') which reduces professionalism. Import order is slightly disorganized (threading appears after from-imports). Overall, the code is compact, uses one action per line, and reads naturally, but small clarity and correctness issues prevent a higher score.
Run 1
1. Code Structure: The small wrapper class is logically organized, though numerous unused imports and the misplaced threading import add clutter. 2. Nesting: Methods are flat and easy to follow, with no nested control flow. 3. Clarity of intent: Class and constructor docstrings explain the compatibility purpose, and names are descriptive. However, getheaders calls the underlying method without returning its result, making its intended behavior unclear. 4. Code length: The class is concise, but the import block is disproportionately large for the shown functionality. 5. Action granularity: Each executable line performs a single action. 6. Reading flow: Methods progress naturally from initialization to accessors; import ordering and limited spacing between top-level elements slightly weaken the flow.
Run 2
Code Structure: The wrapper class is logically organized, but numerous unused imports and the late threading import add clutter. Nesting: Methods are flat, with no unnecessary nesting. Clarity of intent: The class docstring explains its compatibility purpose, and method names are recognizable; however, the informal wording and broad Any annotations reduce precision. The missing return in getheaders makes its intended behavior less clear. Code length: The class is concise, although the imports are excessive for this snippet. Action granularity: Each statement performs a single action. Reading flow: Constructor followed by accessor methods creates a natural progression, but inconsistent spacing between imports, the class, and its docstring slightly weakens presentation.
Run 3
Code Structure: The small wrapper class is logically organized, although imports are poorly grouped and many appear unused in this snippet. Nesting: Methods are flat, with no unnecessary nesting. Clarity of intent: Descriptive names, type annotations, and docstrings explain the adapter's purpose, though Any provides limited type information and getheaders ambiguously discards the underlying result. Code length: The implementation is concise, but the extensive imports add clutter relative to the class's size. Action granularity: Each statement performs one action, making individual lines easy to follow. Reading flow: Initialization followed by accessor methods is natural; inconsistent import placement, limited spacing between sections, and the conversational docstring slightly reduce polish.