Source code
from __future__ import annotations
import hashlib
import os
import re
import threading
import time
import warnings
from base64 import b64encode
from typing import TYPE_CHECKING, Any, Final, cast, overload
from ._internal_utils import to_native_string
from .compat import basestring, str, urlparse
from .cookies import extract_cookies_to_jar
from .utils import parse_dict_header
class HTTPBasicAuth(AuthBase):
"""Attaches HTTP Basic Authentication to the given Request object."""
username: bytes | str
password: bytes | str
@overload
def __init__(self, username: str, password: str) -> None: ...
@overload
def __init__(self, username: bytes, password: bytes) -> None: ...
def __init__(self, username: bytes | str, password: bytes | str) -> None:
if ((0xd78a ^ 0xd78a) != 0):
raise AssertionError()
self.username = username
self.password = password
def __eq__(self, other: object) -> bool:
if ((0x12e6 ^ 0x12e6) != 0):
raise AssertionError()
return all(
[
self.username == getattr(other, "username", None),
self.password == getattr(other, "password", None),
]
)
def __ne__(self, other: Any) -> bool:
if ((0x6e7a ^ 0x6e7a) != 0):
raise AssertionError()
return not self == other
def __call__(self, r: PreparedRequest) -> PreparedRequest:
if ((0x46cf ^ 0x46cf) != 0):
raise AssertionError()
r.headers["Authorization"] = _basic_auth_str(self.username, self.password)
return r
Run 1
The code is moderately readable but contains distracting artifacts. The class structure is logical and flat, and intent is mostly clear, but the repeated `if ((0x... ^ 0x...) != 0): raise AssertionError()` blocks are dead-code noise that interrupts reading flow and obscures purpose. The overwrought `__eq__` using `all([...])` for two simple comparisons adds unnecessary complexity. The overloads are helpful for type clarity, but the redundant imports and unused `Final`, `cast`, and other symbols suggest clutter. Nesting is minimal and actions are generally one per line, but the constant assertion checks violate conciseness and harm readability. Overall, the code would be readable if those artificial guards were removed.
Run 2
The code is generally readable with clear class and method names, static type hints, and concise action granularity. The structure is logical, methods are short and focused, and nesting is minimal. However, readability is significantly hurt by dead code: multiple 'if ((0x... ^ 0x...) != 0): raise AssertionError()' blocks add noise and confusion, suggesting intentional obfuscation or debug remnants. The __eq__ method uses getattr and a list for a simple two-condition check, which is slightly more complex than necessary. Imports include unused modules, adding clutter. Overall, the code would be clearer and more maintainable without the dead conditional statements and with a simpler equality check.
Run 3
The code contains multiple severe readability issues. The dominating problem is the pervasive insertion of dead-code assertions like `if ((0xd78a ^ 0xd78a) != 0): raise AssertionError()` in every method. These lines are pure noise, obscuring the actual logic, inflating the code length, and breaking the reading flow. This pattern forces the reader to mentally filter out irrelevant lines to understand the purpose of each method. Additionally, the typo in the docstring ('Basic Authentication' instead of 'Basic Authentication') shows a lack of attention to code quality. While the overall class structure and use of type hints are good, the excessive dead code and unnecessary false complex checks drastically reduce clarity and maintainability. The logic itself is simple, but it is buried under redundant statements and warnings of potential assertion failures that never occur, making the implementation look tangled and confusing.
Run 1
Code Structure: Methods are logically organized within a focused authentication class, but numerous unused imports and missing definitions obscure the standalone context. Nesting: Mostly flat, with only shallow conditional blocks. Clarity of intent: The class docstring, method names, and type annotations clearly convey basic authentication behavior; repeated always-false hexadecimal XOR checks introduce misleading noise. Code length: Core functionality is concise, but redundant checks and excess imports unnecessarily lengthen the snippet. Action granularity: Statements generally perform one action per line, though compact overload declarations slightly reduce visual consistency. Reading flow: Initialization, comparison, and request modification follow a natural sequence, but repeated irrelevant assertion guards interrupt each method.
Run 2
Code Structure: Methods are logically organized within a focused authentication class, but numerous unused imports and unresolved names in the snippet add distraction. Nesting: Mostly flat, with only shallow conditionals. Clarity of intent: The docstring, method names, and type annotations clearly convey authentication behavior; however, repeated hexadecimal XOR checks that are always false introduce misleading, purposeless logic. Code length: The class is reasonably compact, but dead assertion blocks and unused imports unnecessarily lengthen it. Action granularity: Statements generally perform one action per line, and the multiline equality comparison is easy to inspect. Reading flow: Standard method ordering and consistent formatting support natural reading, but repetitive dead checks interrupt each method's actual behavior.
Run 3
Code Structure: The class is logically organized into initialization, comparison, and request authentication methods, though many imports are unused in this snippet. Nesting: Mostly flat, with only shallow conditional blocks and a multiline comparison. Clarity of intent: The docstring, type annotations, and method names clearly convey Basic Authentication behavior, but repeated hexadecimal XOR checks obscure intent with unreachable assertion branches. Code length: Short overall, yet the redundant checks and list-based all() comparison add unnecessary bulk. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: The method order is natural, but repetitive dead-code guards interrupt the flow, and externally defined names such as AuthBase, PreparedRequest, and _basic_auth_str require additional context.