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, name: str, get_converter: t.Callable[[t.Any], T] | None = None
) -> None:
self.__name__ = name
self.get_converter = get_converter
@t.overload
def __get__(self, obj: None, owner: None) -> te.Self: ...
@t.overload
def __get__(self, obj: App, owner: type[App]) -> T: ...
def __get__(self, obj: App | None, owner: type[App] | None = None) -> T | te.Self:
if obj is None:
return self
rv = obj.config[self.__name__]
if self.get_converter is not None:
rv = self.get_converter(rv)
return rv # type: ignore[no-any-return]
def __set__(self, obj: App, value: t.Any) -> None:
obj.config[self.__name__] = value
Run 1
The code is generally readable and well-structured. It follows common Python patterns for descriptors and uses type hints effectively. The class has a clear purpose (forwarding attribute access to a config dictionary) and the methods are concise, each performing a single logical action. The use of overloaded type signatures improves clarity for type checkers but adds some verbosity for human readers. The getter method is straightforward and handles the None-object case appropriately. Minor readability drawbacks include the slightly obscure use of 'te.Self' (which appears to be a typo for 'typing.Self') and the redundant type ignore comment. Overall, the structure is flat, the naming is clear, and the flow is logical, making it easy to understand for developers familiar with Python descriptors and configuration patterns.
Run 2
The code is generally readable with clear structure and intent. It defines a ConfigAttribute descriptor with type hints, overloads, and docstring. The class is small and logically organized. There are minor issues: the `te` module is referenced but not imported, and the return type annotation in `__get__` is slightly complex, reducing clarity. Nesting is minimal, and each method performs a single logical action. The overloads improve typing but add some verbosity. Overall, it is concise and well-structured, but the undefined `te` and type-annotation complexity prevent a higher score.
Run 3
The code is well-structured and readable. It uses type hints consistently, clear naming, and follows a logical layout. The class is focused and methods are short, with one action per line mostly. Overloads improve clarity for different usage contexts. Minor deductions: the presence of 'te.Self' likely a typo/import issue, and the ignore comment slightly reduces polish. Overall, the code demonstrates strong readability with only minor issues.
Run 1
Code Structure: The descriptor class is logically organized into initialization, overloaded access signatures, retrieval, and assignment. Nesting: Minimal nesting and an early return keep control flow flat. Clarity of intent: The docstring, method names, and type annotations communicate configuration forwarding and optional conversion, though the abbreviated variable 'rv' and undefined names T, te, and App reduce standalone clarity. Code length: Concise overall; overloads add length but provide useful typing information. Action granularity: Statements generally perform one action per line, with no compressed compound operations. Reading flow: Retrieval proceeds naturally from handling class access to looking up, converting, and returning the value. Blank lines separate logical steps well, although stronger spacing between imports and the class and removal of unused imports would improve presentation.
Run 2
Code Structure: The descriptor class is logically organized into initialization, overloaded access signatures, retrieval, and assignment. Nesting: Shallow conditionals and an early return keep control flow simple. Clarity of intent: The docstring, method names, and type annotations clearly convey configuration forwarding with optional conversion, although T, te, and App lack visible definitions, and rv is a vague variable name. Code length: The implementation is concise; overloads add useful typing detail, but several imports are unused in this snippet. Action granularity: Each statement performs a single action, with no compressed multi-action lines. Reading flow: Methods follow a natural order, and whitespace separates retrieval, conversion, and return steps. Missing typing context and limited spacing around top-level declarations slightly reduce standalone readability.
Run 3
Code Structure: The descriptor is logically organized into initialization, getter overloads, getter implementation, and setter. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: The docstring, descriptive member names, and type annotations clearly communicate config forwarding and optional conversion, though T, te, and App are undefined in the supplied snippet, and rv is a less descriptive name. Code length: The implementation is concise, but unused imports add clutter; overloads add length while providing useful typing information. Action granularity: Each executable line generally performs one action. Reading flow: Methods follow a natural sequence, with whitespace separating logical steps, although missing spacing around the class declaration and unresolved typing references slightly interrupt readability.