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 is very readable. Imports are logically grouped (standard, third-party, local) though slightly verbose. The class and method structure is clear and minimal. Nesting is entirely flat with no control flow. Intent is explicit through type hints, descriptive names, and comprehensive docstrings. The `send` method has a long signature, but it is well-documented and uses clear parameter names. Action granularity is good, with one logical action per line (e.g., `super().__init__()`). Reading flow is natural, moving from imports to class definition to abstract methods. The main minor drawback is the sheer number of imports, which adds length but is necessary and organized.
Run 2
The code is highly readable overall. It has clear separation between imports (grouped stdlib, third-party, and local), a single class with a well-defined purpose, and flat structure with no nested logic. Naming and type hints improve clarity. The long import list is acceptable given the adapter's broad responsibility, though it slightly increases length. Docstrings in the methods explicitly explain parameters and behavior, aiding intent. The code is concise, avoids unnecessary nesting, and flows naturally from imports to class definition to method stubs. Minor deductions arise from the extensive import block and the presence of placeholder methods (which may be fine for an abstract base), which slightly limits immediate actionability.
Run 3
The code is highly readable with clear organization. Imports are logically grouped by source (standard library, third-party, local modules) and alphabetized within groups. Class structure is flat and simple with no complex nesting. Intent is explicitly documented through docstrings and type hints. Action granularity is excellent - each import and method parameter occupies its own line. The code length is appropriate for an abstract base adapter, avoiding unnecessary verbosity. Reading flow is natural, moving from imports to class definition to method stubs. Minor improvements could include consolidating some import statements, but the current format enhances diff readability and prevents merge conflicts. The NotImplementedError raises clearly signal abstract methods, making the contract explicit for subclasses.
Run 1
1. Code Structure: Imports are grouped and the adapter interface is logically organized, though many imports are unused in this excerpt. 2. Nesting: Very flat, with no nested control flow. 3. Clarity of intent: Descriptive method names, type annotations, and docstrings clearly communicate the interface; however, PreparedRequest and _t are not defined or imported in the shown code, making annotations harder to interpret. 4. Code length: Method bodies are concise, but extensive imports and parameter documentation outweigh the small implementation. 5. Action granularity: Each statement performs a single action, and the multiline signature is easy to scan. 6. Reading flow: The progression from imports to class initialization and interface methods is natural, although the long import section delays the relevant code.
Run 2
Code Structure: Imports are grouped and the adapter interface is logically organized, though many imports are unused in this excerpt. Nesting: Methods are flat, with no complex branching. Clarity of intent: Descriptive method names, annotations, and docstrings clearly communicate the interface; however, PreparedRequest and _t are not defined or imported here, making the annotations harder to interpret. Code length: The implementation is concise, but the extensive import list and lengthy send docstring outweigh the small amount of functional code. Action granularity: Each statement performs one action, and multiline signatures improve scanning. Reading flow: The progression from imports to class initialization, sending, and cleanup is natural, although the large import block delays reaching the core interface.
Run 3
Code Structure: Imports and the adapter interface are logically organized, although the extensive import block overwhelms the small class. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive method names, type annotations, and parameter documentation clearly communicate the interface; however, PreparedRequest and _t are not defined or imported in the shown code, making annotations harder to interpret. Code length: The class is concise, but many unused imports and a trivial constructor add unnecessary bulk. Action granularity: Each statement performs a single action, and multiline signatures remain readable. Reading flow: The progression from imports to initialization, sending, and cleanup is natural, though the lengthy imports delay the substantive code and spacing between top-level sections could be improved.