Source code
from __future__ import annotations
import os.path
import socket
import typing
import warnings
from typing import Any
from urllib3.exceptions import (
ClosedPoolError,
ConnectTimeoutError,
LocationValueError,
MaxRetryError,
NewConnectionError,
ProtocolError,
ReadTimeoutError,
ResponseError,
)
from urllib3.exceptions import HTTPError as _HTTPError
from urllib3.exceptions import InvalidHeader as _InvalidHeader
from urllib3.exceptions import ProxyError as _ProxyError
from urllib3.exceptions import SSLError as _SSLError
from urllib3.poolmanager import PoolManager, proxy_from_url
from urllib3.util import Timeout as TimeoutSauce
from urllib3.util import parse_url
from urllib3.util.retry import Retry
from .auth import _basic_auth_str
from .compat import basestring, urlparse
from .cookies import extract_cookies_to_jar
from .exceptions import (
ConnectionError,
ConnectTimeout,
InvalidHeader,
InvalidProxyURL,
InvalidSchema,
InvalidURL,
ProxyError,
ReadTimeout,
RetryError,
SSLError,
)
from .models import Response
from .structures import CaseInsensitiveDict
from .utils import (
DEFAULT_CA_BUNDLE_PATH,
get_auth_from_url,
get_encoding_from_headers,
prepend_scheme_if_needed,
select_proxy,
urldefragauth,
)
from ._types import is_prepared as _is_prepared
class BaseAdapter:
def __init__(self) -> None:
super().__init__()
def send(
self,
request: PreparedRequest,
stream: bool = False,
timeout: _t.TimeoutType = None,
verify: _t.VerifyType = True,
cert: _t.CertType = None,
proxies: dict[str, str] | None = None,
) -> Response:
raise NotImplementedError
def close(self) -> None:
raise NotImplementedError
Run 1
The code has clear imports and type hints, which aid readability, but it suffers from several issues. The structure is disorganized: an excessive number of imports are grouped without clear rationale, and the class definition is sparse with no meaningful logic, making it hard to evaluate intent. The nesting is flat, which is good, but the action granularity is poor—empty methods exist only to raise NotImplementedError, and the class has no cohesive purpose shown. The reading flow is broken by blank lines and a lack of comments or docstrings explaining the class's role. Overall, it is readable at a basic syntax level but fails to convey clear intent or structure.
Run 2
The code is generally readable with good organization of imports and clean type hints. However, it loses points for several issues: the class has an unnecessary super().__init__() call with no inheritance, method bodies contain only 'raise NotImplementedError' with excessive blank lines, and there's confusing use of both forward reference types (PreparedRequest, Response) and _t-prefixed type aliases without visible imports. The code is concise but lacks meaningful documentation, making intent unclear. Import structure is logical and well-grouped, but the unused imports at top (socket, os.path) would confuse readers. The nesting is flat which is good, and reading flow is natural, but there's insufficient context to understand the class's purpose or relationships. Mixing private module aliases (_t.TimeoutType) with plain type hints creates inconsistency. While readable at a syntax level, the code could be improved with docstrings, removal of unused imports, and clearer type definitions.
Run 3
The code is a Python module with imports and a base adapter class. Structure is logical with grouped imports, but there are many unused imports (warnings, socket, typing, etc.) and multiple import styles from urllib3 and local modules. The class has clear intent but lacks docstrings and meaningful implementation. The send method has many parameters, reducing readability. Nesting is flat, which is good, but the code is overly verbose due to redundant imports and aliasing. Action granularity is appropriate, but reading flow is disrupted by the excessive import block. Overall, it is a skeleton with room for cleanup and documentation.
Run 1
Code Structure: Imports are broadly grouped and the adapter class has clearly separated methods, but the disproportionately large import block obscures the small interface. Nesting: Very flat, with no nested control flow. Clarity of intent: BaseAdapter, send, close, and NotImplementedError communicate an interface, although missing documentation and unresolved PreparedRequest and _t references make the annotations harder to interpret. Code length: Method definitions are concise, but many imports are unused in this snippet, the constructor adds little, and excess blank lines create unnecessary length. Action granularity: Each statement performs one action, and the multiline signature is easy to scan. Reading flow: The class reads naturally from initialization to sending and cleanup, but inconsistent whitespace and the lengthy imports interrupt the overall flow.
Run 2
Code Structure: Imports precede a clearly organized adapter class, but the extensive unused imports obscure the small implementation. Nesting: Very flat, with no complex branches or nested logic. Clarity of intent: BaseAdapter, send, close, and NotImplementedError clearly signal an interface for subclasses; however, missing documentation and unresolved PreparedRequest and _t references reduce clarity. Code length: Methods are concise, but the import list and excessive blank lines are disproportionate to the functionality shown. Action granularity: Each statement performs one action, and the multiline signature makes parameters easy to scan. Reading flow: The class reads naturally from initialization to sending and cleanup, although inconsistent whitespace and distracting imports interrupt the flow.
Run 3
Code Structure: Imports are grouped before a simple adapter class, but many imports are unused in this snippet. Nesting: Very shallow, with no nested control flow. Clarity of intent: BaseAdapter and its abstract-style send and close methods communicate their roles, but missing docstrings and unresolved PreparedRequest and _t references reduce clarity. Code length: The class is concise, although the lengthy import section overwhelms its small implementation and the constructor adds little value. Action granularity: Each statement performs one action, and multiline signatures improve scanning. Reading flow: Method ordering is natural, but excessive blank lines, trailing whitespace, and inconsistent import organization interrupt an otherwise straightforward presentation.