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."""
lI0O_e104235e = 0xfb3c ^ 0xfb3c
if lI0O_e104235e == 0:
lI0O_e104235e |= 0
else:
lI0O_e104235e &= 0
raise NotImplementedError
Run 1
The code starts with a well-organized import section and clear class/method structure, but it is severely undermined by deliberate obfuscation in the close() method. The variable name lI0O_e104235e is unreadable and the bitwise operations (0xfb3c ^ 0xfb3c, |= 0, &= 0) serve no purpose other than to confuse. This violates clarity of intent, action granularity, and reading flow. The send() method has good documentation and structure, but the close() method destroys overall readability. The code also raises NotImplementedError in both methods, suggesting it is a base class, which is fine, but the obfuscated dead code in close() makes it extremely difficult to understand. Overall, the code is a mix of professional patterns and deliberate sabotage, resulting in a low readability score.
Run 2
The code demonstrates generally good structure with clear imports, type hints, and docstrings. However, it contains a significant readability issue in the close() method where obfuscated variable names (lI0O_e104235e) and meaningless bitwise operations create confusion. The imports are logically grouped but somewhat verbose. The class structure is clear with a proper __init__ and send() method having comprehensive parameter documentation. The send() method signature is well-typed despite many parameters. The close() method's bizarre implementation detracts from otherwise clean code. Nesting is minimal and actions are generally one per line. The code appears to be a legitimate library file with an artifact of code obfuscation or a deliberate example of bad practice mixed with professional code, creating an overall score of 13 out of 20.
Run 3
The code is largely readable: imports are logically grouped, classes and methods are short and clearly documented, and method signatures use modern type hints. However, the weird obfuscated variable in the close() method significantly hurts clarity of intent and reading flow. It introduces unnecessary complexity and suggests either leftover debugging or intentional obfuscation. Additionally, some annotations reference types not imported in the shown snippet (e.g., PreparedRequest, _t), and the unused socket import with a noqa comment adds minor noise. Overall, structure and length are good, but the odd code block and incomplete type context prevent a higher score.
Run 1
Code Structure: Imports and the adapter interface are logically organized, but the extensive imports distract from this small snippet. Nesting: Mostly flat, with only one shallow conditional. Clarity of intent: The send method has a clear signature and explanatory docstring, while close contains an opaque variable and meaningless bitwise operations that obscure its simple purpose. Unresolved annotation names such as PreparedRequest and _t also reduce clarity within the snippet. Code length: The documentation is useful, but the import list and redundant close logic make the code unnecessarily long. Action granularity: Statements generally perform one action per line. Reading flow: The interface reads naturally until the unexplained arithmetic and conditional interrupt close; removing that block would substantially improve readability.
Run 2
Code Structure: Imports and the adapter interface are logically grouped, but many imports are unused in this excerpt. Nesting: Mostly flat, with only a shallow conditional in close(). Clarity of intent: Class and method names, signatures, and docstrings clearly describe the interface, but the obfuscated variable and meaningless bitwise operations obscure close(). PreparedRequest and _t annotations lack visible definitions or imports. Code length: The extensive imports and parameter documentation outweigh the small implementation, while the no-op block adds unnecessary length. Action granularity: Statements generally perform one action per line. Reading flow: Conventional Python layout makes send() easy to follow, but the unexplained obfuscation in close() abruptly disrupts the flow.
Run 3
Code Structure: Imports and the adapter class are logically grouped, but many imports are unused in this snippet. Nesting: Mostly flat, with only a shallow conditional in close(). Clarity of intent: send() has a clear signature and documentation, while close() contains an opaque variable and meaningless bitwise operations that obscure its simple purpose. PreparedRequest and _t are not defined or imported in the snippet, making annotations harder to interpret. Code length: The extensive imports and redundant operations are excessive for this small abstract interface, though the parameter documentation is useful. Action granularity: Each statement performs one action, and multiline formatting is consistent. Reading flow: The class and method layout are natural, but the unexplained obfuscation in close() abruptly disrupts an otherwise conventional interface.