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]):
"""Dictionary lookup object."""
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:
# We need this for type checkers to infer typing
# on attribute access with status_codes.py
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: # type: ignore[override]
# We allow fall-through here, so values default to 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 is generally readable, with clear class naming and straightforward method definitions. However, several issues reduce clarity. The `LookupDict` is described as a dictionary lookup object, but its `__getitem__` and `get` methods read from `__dict__` rather than the dictionary itself, which is confusing and seems unintended. The `__getattr__` method has odd branching: it checks `key in self.__dict__`, returns the value if true, then raises AttributeError in the else, but never actually falls through—making the `if`/`else` redundant. The `__repr__` is concise and clear. The overloads for `get` add some complexity but are manageable. Overall, structure is okay but intent is ambiguous due to the mismatch between class purpose and internal behavior, and the action granularity varies (multiple actions in one line in `__getitem__`). The nesting is minimal, which is a positive.
Run 2
The code is generally well-structured and readable, but has several issues that prevent a higher score. The class hierarchy is clear and methods are logically organized. Nesting is minimal and flat. Naming is good (LookupDict, key, default). Type hints are comprehensive. However, there are logic bugs that harm clarity: __getitem__ and get() use self.__dict__ instead of the dict itself, which makes the intent confusing. The __getattr__ raises AttributeError even when keys exist in __dict__, which seems contradictory. Action granularity is mostly good, though some lines could be broken up. The reading flow is natural, but the inconsistency between using dict inheritance and __dict__ access creates ambiguity. The overloads are well-placed but add complexity. Overall, the structure is sound but the implementation logic makes the intent unclear, earning a moderate score.
Run 3
The code is highly readable with clear structure: a single class with well-documented methods, each performing one focused action. Nesting is minimal (one level in __getattr__ and get methods), maintaining flat structure. Intent is explicit through descriptive names like `__getattr__`, `__getitem__`, and `get`, with helpful docstrings explaining fall-through behavior. Code length is appropriate - no unnecessary verbosity. Type hints and overloads enhance clarity without clutter. Reading flow is natural: class definition, then initialization, representation, attribute access, item access, and method overloading. Comments explain non-obvious typing choices. Minor deductions: the `name: Any` type could be more specific, and the `__dict__` access pattern is slightly unusual, but overall this demonstrates clean, maintainable code that balances documentation with conciseness.
Run 1
Code Structure: Methods are logically grouped in a small class, although unused imports and undefined type variables in the snippet add distraction. Nesting: Minimal nesting makes control flow easy to follow; the else after a return is unnecessary. Clarity of intent: Method names, annotations, and comments explain lookup behavior, but using __dict__ rather than dictionary storage is surprising for a dict subclass, and the class docstring is vague. Code length: Generally concise, with some extra whitespace and typing boilerplate. Action granularity: Each statement performs a single clear action. Reading flow: Initialization, representation, attribute access, item access, and get appear in a natural sequence, though overload declarations slightly interrupt the flow.
Run 2
Code Structure: A well-organized class separates initialization, representation, attribute access, and lookup into focused methods. Nesting: Minimal nesting makes control flow easy to follow, although the else after a return is unnecessary. Clarity of intent: Descriptive method names, annotations, and comments explain most behavior, but looking up values in __dict__ rather than the inherited dictionary is surprising. _VT and _D are not defined in the snippet, and several unused imports add distraction. Code length: Compact overall, with modest overhead from overload declarations that clarify typing. Action granularity: Each line generally performs one action. Reading flow: Methods follow a natural progression, though sparse class documentation and the unconventional storage behavior require extra interpretation.
Run 3
Code Structure: A cohesive class separates initialization, representation, attribute access, and lookup into small methods; however, type variables are not defined in the snippet and some imports appear unused. Nesting: Very shallow, with only one simple conditional. Clarity of intent: Type annotations and comments explain lookup behavior, but storing and retrieving values through __dict__ rather than the inherited dictionary is surprising and deserves clearer documentation. Code length: Concise overall; the else after a return and explicit None default in __dict__.get are unnecessary. Action granularity: Each line generally performs one action, with compact overload declarations remaining readable. Reading flow: Methods follow a natural progression, though excess blank space and typing scaffolding slightly interrupt the flow.