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):
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:
self.username = username
self.password = password
def __eq__(self, other: object) -> bool:
return all(
[
self.username == getattr(other, "username", None),
self.password == getattr(other, "password", None),
]
)
def __ne__(self, other: Any) -> bool:
return not self == other
def __call__(self, r: PreparedRequest) -> PreparedRequest:
r.headers["Authorization"] = _basic_auth_str(self.username, self.password)
return r
Run 1
The code is highly readable with clear logical organization and structure. It uses type hints consistently, follows single responsibility per method, and maintains a flat nesting structure with no deep indentation. Each method serves a distinct, well-defined purpose (initialization, equality, inequality, and request modification). The use of operator overloading demonstrates clear intent. Line lengths are concise, and actions are generally one per line, especially in __call__. Import statements are organized, though some unused imports (hashlib, os, time, etc.) could be removed for cleanliness. The overloaded constructors add minor complexity but are necessary for type safety. Overall, the code flows naturally, is self-documenting through type annotations, and would be easily understood by other Python developers.
Run 2
The code is highly readable due to its clear class definition, logical method ordering, and minimal nesting. Each method has a single, focused action, and the flow from initialization to equality comparison to call behavior is natural. Type hints and overloads improve clarity, while the `__eq__` implementation is concise but clear. The only minor drawbacks are the slight verbosity of `__ne__` and the use of `Any` in one parameter, but these do not significantly impact readability.
Run 3
The code is well-structured and readable with clear separation of methods. The class has a single responsibility, imports are organized, and type hints improve clarity of intent. Nesting is minimal with flat conditionals. However, the `all([...])` in `__eq__` is slightly unnecessary since `all` accepts a generator, and the overloaded constructors add some complexity. The `Final` import and two-string imports from `.compat` are unused, creating minor ambiguity. Overall, the code is concise, logically organized, and follows a natural reading flow, losing points only for minor redundancy and unused imports.
Run 1
Code Structure: The class is logically organized, with attributes, constructor overloads, initialization, comparisons, and request handling clearly separated. Nesting: Methods are flat, with no complex control flow. Clarity of intent: HTTPBasicAuth, descriptive credential names, and type annotations communicate the purpose well, though AuthBase, PreparedRequest, and _basic_auth_str are not defined in the excerpt, and r is terse. Code length: The class is concise, but numerous unused imports and extra blank lines add clutter; the all([...]) comparison is more verbose than a direct conjunction. Action granularity: Each statement performs one clear action, apart from conventional one-line overload declarations. Reading flow: Method ordering is natural and easy to follow, although the crowded import section and absent explanatory docstring slightly reduce readability.
Run 2
Code Structure: The class is logically organized into attributes, initialization, equality checks, and request authentication, although numerous unrelated imports add clutter. Nesting: Methods are flat, with no complex branching or deep nesting. Clarity of intent: Descriptive class and attribute names, type annotations, and straightforward methods communicate the purpose clearly; undefined surrounding dependencies and the abbreviated parameter r slightly reduce standalone clarity. Code length: The implementation is compact, but overload declarations and the list passed to all make simple operations somewhat verbose. Action granularity: Each statement performs one clear action. Reading flow: Method ordering is natural and consistent, though extra blank lines and the crowded import section mildly interrupt the flow.
Run 3
Code Structure: The class is logically organized into typed attributes, initialization, comparison methods, and request authorization, though many imports are unused in this excerpt. Nesting: Minimal nesting keeps the code easy to scan. Clarity of intent: Descriptive class and attribute names, type annotations, and the Authorization assignment clearly convey basic authentication; AuthBase, PreparedRequest, and _basic_auth_str are not defined or imported in the excerpt. Code length: Compact overall, but overloads and the all([...]) comparison add verbosity compared with simpler alternatives. Action granularity: Each statement performs a single clear action; the inline overload declarations remain understandable. Reading flow: Methods follow a natural sequence, but excessive blank space after the class declaration and the large import block slightly disrupt flow.