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. Clear class definition, type hints, and concise docstrings. Methods are logical, with flat nesting and one action per line. The use of 'overload' increases clarity for the 'get' method. Minor readability issues: '__getitem__' is defined but appears incomplete relative to normal dict indexing semantics, and 'name' as 'Any' reduces type safety. The '__getattr__' uses '__dict__' access rather than instance attribute. Overall concise, well-organized, and easy to follow, though a few small design quirks prevent a higher score.
Run 3
The code is generally readable and well-structured. It uses clear naming conventions, has reasonable nesting depth (only one level in __getattr__), and maintains a logical organization with type hints and docstrings. Each method has a single responsibility and actions are separated per line. The use of overloads for the get method is clear and helps with type safety. However, there are some readability concerns: the __getitem__ method has a type ignore comment and overrides dict behavior in a potentially confusing way, and the fall-through behavior of __getitem__ returning None rather than raising KeyError might be unclear to readers not familiar with the library's conventions. Additionally, the __getitem__ method ignores the self dict entirely, using self.__dict__ instead, which could be confusing since LookupDict inherits from dict. The code could be slightly more explicit about its intent in this override.
Run 1
Code Structure: Methods are logically grouped within a small class, although unused imports and undefined type variables in the snippet add distractions. Nesting: Very shallow, with only one simple conditional. Clarity of intent: Type annotations, descriptive method names, and comments help, but using instance attributes rather than dictionary entries for lookup is surprising and insufficiently explained. Code length: Concise overall; the unnecessary else after a return and redundant None argument slightly reduce economy. Action granularity: Each line generally performs a single action; compact overload declarations remain readable. Reading flow: Initialization, representation, and lookup methods follow a natural order, though the interaction between inherited dict behavior and attribute-backed lookups requires extra thought.
Run 2
Code Structure: Imports and a single class with small, clearly separated methods provide logical organization. Nesting: Minimal nesting makes the code easy to scan; the else after a return is unnecessary. Clarity of intent: Method names, annotations, and comments explain lookup behavior, but using instance attributes rather than dictionary entries is surprising for a dict subclass. The generic docstring and undefined-in-snippet type variables _VT and _D reduce clarity. Code length: Concise overall, though overloads add visual weight and several imports appear unused. Action granularity: Each line generally performs one action, with compact overload declarations remaining understandable. Reading flow: Initialization, representation, attribute lookup, item lookup, and get follow a natural progression. Minor spacing inconsistencies and the unusual storage semantics slightly interrupt readability.
Run 3
Code Structure: The class is logically organized into initialization, representation, attribute access, and lookup methods. Nesting: Control flow is shallow, with only one simple conditional. Clarity of intent: Method names, annotations, and comments explain most behavior, but using __dict__ rather than inherited dictionary storage is surprising, and _VT and _D are not defined in the snippet. Code length: Methods are concise, although several unused imports and a redundant else add minor clutter. Action granularity: Each line generally performs one clear action. Reading flow: The progression is natural and formatting is consistent, though overload declarations and typing details slightly interrupt the otherwise straightforward flow.