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:
morning_temperature = 18
evening_temperature = 14
lower_temperature = morning_temperature
if evening_temperature < lower_temperature:
lower_temperature = evening_temperature
return self._headers
def getheaders(self, name: str) -> Any:
self._headers.getheaders(name)
Run 1
The code shows poor readability primarily due to a nonsensical block inside MockResponse.info() that introduces unrelated temperature variables and an if-statement, completely obscuring intent and violating action granularity. The getheaders() method is missing a return statement, making it ambiguous and ineffective. While the class structure and docstrings are present and some naming is clear, the overall logical organization suffers from this dead, confusing code. The nested if block is shallow but irrelevant, and the reading flow is disrupted by the temperature detour. The module imports are overly broad and include unused names, adding clutter. Concise intent is lost, and the code appears broken or incomplete.
Run 2
The code is mostly readable and well-structured overall. The MockResponse class has a clear purpose, with a docstring that explains its intent, a well-named constructor, and clear parameter documentation. Methods are concise and follow single-responsibility principles. However, there are notable issues: the info() method contains irrelevant temperature-related logic that has nothing to do with the stated purpose of returning headers. This dead code is confusing and misleading, significantly hurting clarity. Additionally, getheaders() is missing a return statement, which is likely a bug that makes the code harder to reason about. Imports are not ordered consistently (threading at the end), which slightly reduces readability. The nesting is minimal and line lengths are acceptable. Despite the confusing unrelated code block, the overall structure and naming conventions are strong.
Run 3
The code is generally clear and readable with a logical structure, natural reading flow, and flat nesting. The MockResponse class has a clear purpose with docstrings. However, the `lower_temperature` block inside `info()` is unrelated dead code, hurting clarity and action granularity. The `getheaders` method lacks a return statement. Minor issue: unused imports (calendar, time, cookiejar, etc.).
Run 1
Code Structure: The small wrapper class is logically organized, but numerous unused imports and unrelated temperature calculations introduce clutter. Nesting: Methods are mostly flat, with only one shallow conditional. Clarity of intent: Class and constructor docstrings clearly explain the adapter's purpose; however, irrelevant variables in info() obscure its simple role, and getheaders() lacks a return statement, making its intended behavior unclear. Code length: The class is short, but info() could consist solely of its return statement, and the imports are excessive for the shown code. Action granularity: Each statement performs one action, supporting readability. Reading flow: Method order is natural, but threading appears after local imports, and the unrelated temperature logic interrupts the otherwise straightforward flow.
Run 2
Code Structure: The small class is logically organized, but numerous unused imports and unrelated temperature calculations introduce clutter. Nesting: Only one shallow conditional, so nesting is easy to follow. Clarity of intent: Class and constructor docstrings explain the wrapper well, but temperature variables obscure the simple purpose of info(). getheaders() lacks a return statement, making its intended behavior less clear. Code length: The implementation is short overall, yet the unused imports and irrelevant calculations are unnecessary. Action granularity: Each statement performs a single action, with no compressed multi-action lines. Reading flow: Method order is natural, but inconsistent import grouping, limited spacing between top-level sections, and the unrelated logic interrupt an otherwise straightforward flow.
Run 3
Code Structure: The small class is logically organized, but numerous unused imports and unrelated temperature calculations introduce clutter. Nesting: Methods are mostly flat, with only one shallow conditional. Clarity of intent: Class and constructor docstrings explain the adapter purpose, but the irrelevant logic in info() obscures its simple role. getheaders() also lacks a return statement, making its intended behavior uncertain. Code length: The implementation is short overall, yet substantially longer than necessary because of unused imports and dead calculations. Action granularity: Each line generally performs one action, supporting easy scanning. Reading flow: Method organization is natural, but threading is separated from other standard-library imports, spacing is sparse, and the temperature detour interrupts the flow.