Source code
from __future__ import annotations
from collections import OrderedDict
from collections.abc import Iterable, Iterator, Mapping
from typing import Any, Generic, TypeVar, overload
from .compat import MutableMapping
class LookupDict(dict[str, _VT]):
name: Any
def __init__(self, name: Any = None) -> None:
self.name = name
super().__init__()
def __repr__(self) -> str:
return f"<lookup '{self.name}'>"
def __getattr__(self, key: str) -> _VT | None:
if key in self.__dict__:
return self.__dict__[key]
else:
raise AttributeError(
f"'{type(self).__name__}' object has no attribute '{key}'"
)
def __getitem__(self, key: str) -> _VT | None:
return self.__dict__.get(key, None)
@overload
def get(self, key: str, default: None = None) -> _VT | None: ...
@overload
def get(self, key: str, default: _D | _VT) -> _D | _VT: ...
def get(self, key: str, default: _D | None = None) -> _VT | _D | None:
return self.__dict__.get(key, default)
Run 1
The code has clear intent and relatively short methods, but suffers from structural and logical issues that hurt readability. The class inherits from dict but bypasses dictionary storage, instead using __dict__ for lookups, which is confusing and misleading. __getitem__ and get() access __dict__ rather than dictionary items, deviating from expected Mapping behavior. __getattr__ contains unnecessary nesting with an if-else where a guard clause or direct implementation would be cleaner. There are also trailing whitespace and blank lines that disrupt visual flow. Type hints are present, which aids clarity, but the use of Any for 'name' is overly broad. Method purposes are understandable individually, but the overall class design is counterintuitive. The code is reasonably concise, but the mismatch between inheritance and behavior, combined with minor formatting issues, significantly reduces readability.
Run 2
The code has a clear purpose and reasonable structure, but several issues reduce readability. The LookupDict extends dict but overrides __getitem__ to access __dict__ instead of dictionary items, creating confusing behavior. Type annotations and overloads are present, which is good, but some are inconsistent (e.g., __getitem__ returns _VT | None while __getattr__ may raise). The __getattr__ method contains an if-else that could be simplified, and the method implementation seems redundant since dict already provides get. The code includes unnecessary blank lines and comments, and the __dict__ access pattern is confusing for a dict subclass. The class is relatively short and flat, which helps, but the intent behind overriding dictionary methods to access instance attributes is unclear without additional context. Variable naming is reasonable, but the overall design feels inconsistent with expected dict behavior, reducing clarity for future maintainers.
Run 3
The code is generally readable with clear class structure and type hints, but has some inconsistencies that reduce clarity. The inheritance from dict[str, _VT] conflicts with the actual implementation using __dict__ storage, making intent ambiguous. The __getattr__ method has an unnecessary else after raise, and the logic for attribute lookup is convoluted. __getitem__ silently returns None instead of raising KeyError, which violates dict expectations. Action granularity is mostly fine with one action per line, but the type variables _VT and _D are undefined in the shown code, creating confusion. The overloads are properly structured, though the class's purpose as a 'lookup' dictionary is muddled by mixing dict inheritance with __dict__ access. Overall, the code needs better documentation and consistent implementation patterns to improve readability.
Run 1
Code Structure: Methods are logically grouped within a small class, although unused imports and undefined type variables (_VT and _D) make the snippet less self-contained. Nesting: Minimal nesting keeps control flow straightforward; the else after a return is unnecessary. Clarity of intent: Method names and type annotations help, but attribute-backed lookup in a dict subclass is surprising and lacks explanation. Code length: Concise overall, with some distracting blank lines and redundant syntax. Action granularity: Each line generally performs one action. Reading flow: The progression from initialization to representation and lookup methods is natural, but inconsistent whitespace and unexplained lookup semantics interrupt readability.
Run 2
Code Structure: Methods are logically grouped within a small class, but unused imports and undefined type variables distract. Nesting: Very shallow; the only conditional is easy to follow, though its else is unnecessary after a return. Clarity of intent: Method names and type annotations help, but using instance attributes rather than dictionary storage for lookups is surprising and unexplained. Code length: Concise overall, with useful overloads, but excessive blank lines and unused imports add clutter. Action granularity: Each line generally performs one action, making individual operations easy to understand. Reading flow: Initialization, representation, and lookup methods appear in a natural order, although inconsistent whitespace and missing context for _VT and _D interrupt comprehension.
Run 3
Code Structure: Methods are logically organized in a compact class, but unused imports and undefined type variables distract. Nesting: Very shallow, with only one simple conditional; the else after a return is unnecessary. Clarity of intent: Method names and annotations help, but using instance attributes rather than dictionary entries for lookup is surprising and unexplained. Code length: Concise overall, though excess blank lines and unused imports add clutter; overloads add useful typing detail. Action granularity: Each statement performs one clear action. Reading flow: The progression from initialization to representation and lookup is natural, but inconsistent whitespace and missing context for _VT and _D interrupt comprehension.