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 AuthBase:
"""Base class that all auth implementations derive from"""
def __call__(self, r: PreparedRequest) -> PreparedRequest:
raise NotImplementedError("Auth hooks must be callable.")
Run 1
The code is highly readable. It begins with clear future import and standard imports, organized logically (standard library, then local modules). Constants like `Final` are properly imported. The `AuthBase` class has a clear docstring and a single, focused method with a descriptive parameter type hint and return type. Nesting is non-existent, action granularity is one action per line, and overall structure is flat. The only minor deduction is that some imported names (e.g., `overload`, `cast`, `Any`) are not used in the shown code, which slightly reduces clarity of intent for a reviewer seeing only this fragment.
Run 2
The code is generally readable with clear structure: imports are logically grouped (standard library, then third-party, then local), and the class definition is simple with a single method. The intent of the AuthBase class is immediately clear from its docstring and the NotImplementedError message. Nesting is minimal, action granularity is appropriate, and the reading flow is natural. However, the score is reduced because some imports appear unnecessary for this snippet (hashlib, os, re, threading, time, warnings, b64encode, urlparse, extract_cookies_to_jar, parse_dict_header), which introduces ambiguity about whether this is a partial file or contains unused dependencies. Additionally, the use of 'basestring' and 'str' from a compat module suggests legacy compatibility code, which may confuse readers unfamiliar with the project's conventions. The 'Final' import and 'cast' from typing are defined but unused here, further reducing clarity. Overall, it is clean but slightly cluttered by imports that don't contribute to the visible code's purpose.
Run 3
The code is highly readable and well-structured. It demonstrates clean organization with clear separation of imports (standard library, third-party, then local modules), logical grouping, and proper use of type hints and future imports. The class `AuthBase` has a single clear responsibility as a base class, with a concise, well-documented `__call__` method that clearly describes its contract. The code is flat with no nesting, uses appropriate abstraction level, and each line represents a single action. Imports are alphabetized and grouped logically. The only minor deductions are for the `cast` import which appears unused in the visible snippet and the slight verbosity of importing many symbols, but this is negligible. Overall, the intent is immediately clear, and the reading flow is natural.
Run 1
Code Structure: Imports precede a small, logically organized base class, though many imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, docstring, and explicit NotImplementedError clearly establish an authentication interface; the parameter name 'r' is vague, and PreparedRequest is not defined or imported here. Code length: The class is concise, but the extensive imports are disproportionate to the shown functionality. Action granularity: Each import and statement occupies its own line, with no compressed operations. Reading flow: The class reads naturally, although separating import groups and adding another blank line before the class would improve visual organization.
Run 2
Code Structure: Imports followed by a small base class provide clear, logical organization, although many imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The class name, docstring, typed method signature, and explicit NotImplementedError clearly communicate an authentication interface; however, PreparedRequest is not defined or imported in the shown code. Code length: The implementation is concise, but the extensive imports add unnecessary visual weight relative to the small class. Action granularity: Each statement occupies its own line, with no compressed multi-action statements. Reading flow: The progression from dependencies to class documentation to the callable contract is natural, though additional blank lines separating import groups and the top-level class would improve presentation.
Run 3
Code Structure: Imports precede a clearly defined authentication base class, providing logical organization, though many imports are unused in this snippet. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, docstring, typed callable interface, and explicit NotImplementedError clearly communicate the abstraction's purpose; PreparedRequest is not defined or imported in the excerpt. Code length: The implementation is concise, but the extensive import list distracts from its small scope. Action granularity: Each import and statement occupies its own line. Reading flow: The progression from imports to class documentation to method is natural, although additional spacing between import groups and the class would improve readability.