Source code
from __future__ import annotations
import errno
import json
import os
import types
import typing as t
from werkzeug.utils import import_string
class ConfigAttribute(t.Generic[T]):
"""Makes an attribute forward to the config"""
def __init__(
self, a: str, b: t.Callable[[t.Any], T] | None = None
) -> None:
self.__name__ = a
self.get_converter = b
@t.overload
def __get__(self, c: None, d: None) -> te.Self: ...
@t.overload
def __get__(self, e: App, f: type[App]) -> T: ...
def __get__(self, g: App | None, h: type[App] | None = None) -> T | te.Self:
if g is None:
return self
i = g.config[self.__name__]
if self.get_converter is not None:
i = self.get_converter(i)
return i # type: ignore[no-any-return]
def __set__(self, j: App, k: t.Any) -> None:
j.config[self.__name__] = k
Run 1
The code is extremely difficult to read due to single-letter variable names that obscure meaning (a, b, c, d, e, f, g, h, i, j, k), even though the class purpose is clear. The descriptors and overloads use placeholders that don't explain their roles. The __init__ parameters 'a' and 'b' could be 'name' and 'converter', for example. Type hints are present but hard to follow because they reference undefined 'te' and 'App'. No comments explain the overload logic. The code is heavily nested and mixes descriptor logic with type-checking workarounds. Action granularity is okay, but reading flow is broken by poor naming. While the structure is logical, the lack of descriptive names makes it nearly unreadable for anyone new to the codebase.
Run 2
The code uses short, cryptic single-letter variable names (a, b, c, d, e, f, g, h, i, j, k) throughout, severely undermining clarity of intent and reading flow. While the structure is logically organized (class, init, get, set) and nesting is minimal, the naming choices make it unnecessarily hard to follow. The overloads are present but poorly documented; the type signatures are difficult to parse quickly due to the generic one-letter parameters. The code length is reasonable, but action granularity and intent are obscured by the terse naming. A developer would spend more time deciphering what each variable represents than understanding the logic. The config-forwarding pattern is common, but the implementation here reads like a obfuscated version of what should be straightforward descriptor code.
Run 3
This code is difficult to read due to meaningless parameter names (a, b, c, d, e, f, g, h, i, j, k), which obscure the intent of the methods. The type annotations are extensive but use single-letter variables, making signatures hard to parse. There is unnecessary type complexity (overloads and generic Self) that adds noise rather than clarity. Nesting is flat, and action granularity is acceptable, but the poor naming, ambiguous identifiers, and lack of comments explaining the descriptor's behavior or converter expectations significantly reduce readability. The import block is clean, but the core class definition lacks explanatory structure. Overall, the code conveys what it does only after careful decoding, not at a glance.
Run 1
Code Structure: The descriptor class is logically organized into initialization, overloaded access, and assignment methods, although unused imports and undefined typing names add distractions. Nesting: Shallow conditionals and an early return make control flow easy to follow. Clarity of intent: The docstring and config access suggest the purpose, but single-letter parameter and variable names obscure roles; T, te, and App lack definitions or imports in the snippet. Code length: The implementation is reasonably concise, though imports and typing declarations add overhead. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: Method ordering is natural, but cryptic names and unresolved type references interrupt comprehension.
Run 2
Code Structure: The descriptor class is logically organized into initialization, overloaded access, and assignment methods, but unused imports and undefined references (T, te, App) distract. Nesting: Shallow conditionals make control flow easy to follow. Clarity of intent: The docstring and method names convey configuration forwarding, but single-letter parameters and variables obscure their roles. Code length: The implementation is compact, although imports and overload declarations add overhead. Action granularity: Statements generally perform one action per line. Reading flow: Method order is natural, but inconsistent parameter names across overloads and implementation, unexplained type dependencies, and sparse contextual documentation interrupt comprehension.
Run 3
Code Structure: The descriptor is logically organized into initialization, overloaded access, and assignment methods, although unused imports and undefined typing names add distractions. Nesting: Control flow is shallow and easy to follow. Clarity of intent: The docstring and method names explain config forwarding, but single-letter parameters and variables obscure their roles; T, te, and App lack definitions or imports in the snippet. Code length: The implementation is concise, though overload declarations and unused imports add overhead. Action granularity: Each statement performs one clear action, with no crowded multi-operation lines. Reading flow: Standard method ordering and whitespace support natural reading, but cryptic names and unresolved references force readers to infer context.