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 and follows Python conventions well. It has good type hints, docstrings, and clear method separation. The class structure is logical with each method serving a distinct purpose. Nesting is minimal, and the reading flow is natural. However, there's a potential inconsistency: __getitem__ and get() use self.__dict__ rather than the dict's storage, which could be confusing. The __getattr__ method has an if-else that could be simplified to raise directly after the if. The overload decorators add complexity but are justified for type checking. Overall, the code is maintainable but could benefit from a comment explaining why __dict__ is used instead of the inherited dict storage, and the __getattr__ could be flattened slightly.
Run 2
The code is generally readable and well-structured. It has a clear class hierarchy, concise methods, and flat nesting. Type hints and overloads improve clarity, and docstrings/comments explain intent. Minor issues: using self.__dict__ directly instead of super().get() for dict lookups slightly obscures intent, and the __getattr__/__getitem__ logic could confuse readers unfamiliar with the fall-through behavior. Overall, it is concise, organized, and easy to follow.
Run 3
The code is generally clear and well-structured, with a concise class definition and good use of type hints. It has a logical layout: imports, class declaration, init, repr, attribute access, item access, then overloaded get methods. Nesting is minimal, and each method performs a single action, contributing to good action granularity. The reading flow is natural, and intent is fairly clear, especially with the explanatory comments for __getattr__ and __getitem__. However, the use of __getitem__ returning None as a fall-through might be ambiguous without context, and the overload definitions slightly increase length but improve clarity. The code is concise but could benefit from a docstring explaining the fall-through behavior more explicitly. Overall, it is highly readable with only minor clarity improvements needed.
Run 1
Code Structure: Methods are logically grouped within a small class, though unused imports and undefined type variables in the snippet distract. Nesting: Minimal nesting makes control flow easy to follow; the else after a return is unnecessary. Clarity of intent: Method names, annotations, and comments help, but using __dict__ rather than dictionary storage is surprising, and the class docstring does little to explain that behavior. Code length: Generally concise, although overloads and typing details add visual weight. Action granularity: Each statement performs one clear action. Reading flow: Initialization, representation, attribute access, and lookup methods follow a natural sequence, with consistent formatting and spacing.
Run 2
Code Structure: Imports and a single class with small, logically grouped methods provide clear organization, though _VT and _D are not defined in the snippet. Nesting: Control flow is shallow, with only one if/else branch. Clarity of intent: Type annotations and comments explain lookup behavior, but the generic docstring and use of __dict__ rather than dictionary entries make the interface somewhat surprising. Code length: Concise overall; the else after return and explicit None argument to get are mildly redundant. Action granularity: Statements generally perform one action per line; compact overload declarations remain understandable. Reading flow: Methods progress naturally from initialization and representation to lookup operations, although typing machinery and an extra blank line slightly interrupt the flow.
Run 3
Code Structure: Imports and a single class with short, focused methods provide clear organization, though _VT and _D are not defined in the excerpt and several imports are unused. Nesting: Minimal nesting makes control flow easy to follow; the else after return is unnecessary. Clarity of intent: Method names, annotations, and comments explain lookup behavior, but storing lookups in __dict__ rather than the inherited dictionary is surprising, and the class docstring is vague. Code length: Concise overall, with some annotation and overload verbosity that supports typing. Action granularity: Statements generally perform one action per line. Reading flow: Methods follow a natural progression from initialization and representation to lookup operations, although an extra blank line and unexplained type variables slightly interrupt comprehension.