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:
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 has a clear purpose and mostly follows standard class structure, but suffers from several readability issues. The __eq__ method has poor formatting with awkward indentation and unnecessary line breaks that disrupt reading flow. The __init__ method uses overloads followed by a concrete implementation, which is good for type clarity but adds length. Multiple methods are packed together without blank lines between them, violating PEP 8 spacing conventions and making the class feel cramped. The __call__ method is clear and concise, but the overall structure lacks consistent spacing between method definitions. Variable names are descriptive, and type hints improve clarity. However, the formatting inconsistencies—especially in __eq__—create visual noise that obscures intent. The code would benefit from proper spacing, cleaned-up __eq__ formatting, and more consistent organization.
Run 2
The code shows some good practices like type hints, overloads, and a clear class purpose, but it suffers from significant readability issues. The __eq__ method has bizarre spacing and inconsistent alignment, making it visually confusing and hard to parse. Multiple methods are crammed together without blank lines between them, violating PEP 8 and disrupting the reading flow. The nested all() call with a list containing oddly formatted expressions adds unnecessary complexity. While the overall structure is logical and the class is concise, the inconsistent formatting and lack of visual separation between methods make the code feel tangled and unpolished. The intent is mostly clear but the execution undermines readability.
Run 3
The code has several readability issues. The __eq__ method has awkward formatting with excessive whitespace and misaligned elements, making it difficult to parse visually. The overload decorators add complexity without clear immediate benefit. Type hints are inconsistent in style and placement. Some imports appear unused or overly broad. The class structure is logical but the methods lack consistent spacing and organization. The reading flow is interrupted by the poorly formatted comparison method. While the code is functional, the formatting inconsistencies, unnecessary line breaks in some places, and tight spacing in others reduce overall readability. The intent of most methods is clear, but presentation undermines comprehension.
Run 1
Code Structure: The class logically groups initialization, equality, and request authentication, but numerous unused imports and missing spacing between methods add clutter. Nesting: Very shallow, making control flow easy to follow. Clarity of intent: The docstring, method names, and type annotations clearly communicate Basic Authentication behavior; referenced types and helpers are not defined in the snippet. Code length: The class is concise, although the import block is disproportionately large and equality checking uses an unnecessarily elaborate all/list construction. Action granularity: Most lines perform one action, but both equality comparisons share a crowded line. Reading flow: Methods follow a natural sequence, yet inconsistent whitespace and awkward formatting in __eq__ interrupt scanning.
Run 2
Code Structure: The class logically groups initialization, comparison, and request authentication, but inconsistent method spacing and numerous unused imports add clutter. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The class docstring, descriptive attribute names, and type annotations clearly communicate its purpose; AuthBase, PreparedRequest, and _basic_auth_str are not defined in the excerpt, limiting standalone understanding. Code length: Methods are concise, although the all() expression is unnecessarily elaborate for two comparisons. Action granularity: Most lines perform one action, but both equality comparisons are awkwardly placed on the same line. Reading flow: Method order is natural, but irregular whitespace in __eq__ and missing blank lines between some methods interrupt scanning.
Run 3
Code Structure: The class logically groups initialization, equality checks, and request authentication, but unused imports and inconsistent method spacing add clutter. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The class docstring, descriptive names, and type annotations communicate its purpose well, although AuthBase, PreparedRequest, and _basic_auth_str are not defined or imported in the snippet. Code length: Methods are concise, but the import list is disproportionate to the shown functionality, and the equality implementation could be simpler. Action granularity: Most lines perform one action, but both equality comparisons share an awkwardly formatted line. Reading flow: The methods follow a natural sequence, yet irregular whitespace, missing blank lines between methods, and malformed-looking alignment in __eq__ interrupt scanning.