Source code
from __future__ import annotations
import os.path
import socket # noqa: F401
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:
"""The Base Transport Adapter"""
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:
"""Sends PreparedRequest object. Returns Response object.
:param request: The :class:`PreparedRequest <PreparedRequest>` being sent.
:param stream: (optional) Whether to stream the request content.
:param timeout: (optional) How long to wait for the server to send
data before giving up, as a float, or a :ref:`(connect timeout,
read timeout) <timeouts>` tuple.
:type timeout: float or tuple
:param verify: (optional) Either a boolean, in which case it controls whether we verify
the server's TLS certificate, or a string, in which case it must be a path
to a CA bundle to use
:param cert: (optional) Any user-provided SSL certificate to be trusted.
:param proxies: (optional) The proxies dictionary to apply to the request.
"""
raise NotImplementedError
def close(self) -> None:
"""Cleans up adapter specific items."""
raise NotImplementedError
Run 1
The code has clear organization and intent in its imports and class structure, but it suffers from inconsistent formatting that harms readability. The import statements are logically grouped with reasonable aliasing, and the class methods are well-documented with clear docstrings and type hints. However, there are several formatting issues: multiple imports appear on single lines with awkward spacing (e.g., 'InvalidHeader, InvalidProxyURL'), which creates visual clutter. The send() method signature has irregular spacing with some parameters on one line and others spread across multiple lines inconsistently. The action granularity is generally good, but the inconsistent alignment and spacing make the code harder to scan. The nesting is minimal and the methods are appropriately short, but the overall flow is disrupted by formatting irregularities. The code appears to be a partial implementation or interface definition, which limits assessment of deeper structural quality. With consistent formatting and adherence to PEP 8 conventions, this would be significantly more readable.
Run 2
The code has a logical structure with clear imports and a simple class definition, but suffers from inconsistent formatting that hurts readability. The import section is well-organized by source but has unusual spacing and alignment (e.g., 'socket # noqa: F401', uneven column alignment in parenthesized imports). The `send` method signature has excessive whitespace between parameter names and type hints, disrupting natural reading flow. While the method's docstring is thorough and clearly explains parameters, the signature formatting contradicts the docstring's professionalism. Nesting is minimal and action granularity is fine. The class structure is clear, but single-line method definitions with `raise NotImplementedError` feel cramped. Overall, the code is readable but inconsistent formatting choices reduce clarity, making it appear unpolished. With normal formatting, this would score significantly higher.
Run 3
The code shows inconsistent formatting, particularly in imports and function signatures. Multiple imports are packed on single lines with unusual spacing, reducing scanability. The `send` method signature is broken across lines awkwardly, making parameter identification difficult. While the class structure is logical and docstrings are helpful, the alignment issues and inconsistent spacing between imports and parameters disrupt reading flow. The code is functional but not cleanly formatted, lowering readability.
Run 1
Code Structure: Imports followed by a small adapter class provide logical organization, although import grouping and spacing are inconsistent. Nesting: Minimal nesting makes the class easy to scan. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly communicate the transport interface; however, PreparedRequest and _t are not defined or imported in the snippet, making annotations harder to interpret. Code length: The class is concise, but the large import section is disproportionate to the functionality shown, with many imports unused here. Action granularity: Executable statements perform one action per line, though multiple imported names and parameters are awkwardly packed onto some lines. Reading flow: The progression from imports to initialization, sending, and cleanup is natural, but irregular whitespace, uneven line wrapping, and limited separation between sections interrupt readability.
Run 2
Code Structure: Imports precede a clearly defined adapter interface, but numerous unused imports and missing definitions for PreparedRequest and _t obscure context. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly communicate the adapter contract, although unresolved annotation names reduce clarity. Code length: The implementation is concise, but the import block is disproportionately large for the functionality shown. Action granularity: Executable statements perform one action per line; however, several imports and parameters are crowded onto single lines. Reading flow: The progression from imports to initialization, sending, and cleanup is logical, but inconsistent spacing, awkward line breaks, and limited separation between sections interrupt scanning.
Run 3
Code Structure: Imports followed by a small adapter class provide logical organization, but numerous unused imports and unresolved annotation names add clutter. Nesting: Methods are flat, with no complex branching. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly convey the adapter interface, although PreparedRequest and _t are not defined or imported in the snippet. Code length: The class is concise, but the extensive imports and lengthy send docstring outweigh its minimal implementation. Action granularity: Executable statements each perform one action per line; crowded import lists and signature parameters reduce visual clarity. Reading flow: The class reads naturally from initialization to sending and cleanup, but inconsistent spacing, awkward line breaks, and dense parameter formatting interrupt scanning.