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 not (key in self.__dict__):
raise AttributeError(
f"'{type(self).__name__}' object has no attribute '{key}'"
)
else:
return self.__dict__[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 logically structured with clear intent, particularly in type annotations and docstrings, but readability suffers from several issues. The `LookupDict` class extends `dict` but implements `__getitem__` and `get` by delegating to `__dict__` instead of the dict itself, which is confusing and likely a semantic mismatch. Nesting is mostly flat, which is good, but action granularity is mixed: some methods have unnecessary conditionals (e.g., `if not (key in self.__dict__)`), and the `__getattr__` branch could be simplified. The type overloads add verbosity without clear benefit for human readers. The `__getitem__` method's comment contradicts the implementation—it says values default to None but `get` may return other defaults. Overall, the code is moderately readable but requires domain knowledge to interpret correctly.
Run 2
The code is generally readable with clear structure and intent. It defines a custom dictionary with well-documented methods, appropriate use of type hints, and logical organization. Nesting is minimal, action granularity is reasonable, and reading flow is natural. However, a few aspects reduce clarity: the __getitem__ method uses self.__dict__ rather than the dictionary itself, which can be confusing; the __init__ calls super() before assigning name, which is okay but slightly odd; and the overloads, while useful, add some complexity. The code is concise but not excessively so. Overall, it is quite readable, deserving a score of 16.
Run 3
The code is generally clear and well-structured. It uses type hints effectively, has logical organization with a single class, and maintains flat nesting. Each method is concise and performs a focused action. The docstring and comments explain non-obvious behavior (e.g., fall-through defaults, type checker inference). However, readability is slightly reduced by the use of `__dict__` lookups instead of standard dictionary operations, which may confuse readers unfamiliar with the intent. The `__getitem__` method's override comment is helpful but terse. The overloading of `get` adds some complexity but is justified for type clarity. Overall, it reads naturally and follows Python conventions well, but the unconventional attribute/dict interaction and type-checker-oriented comments make it slightly less approachable for general readers.
Run 1
Code Structure: Imports and a single class with short, focused methods provide clear organization, though _VT and _D are not defined in the snippet and several imports are unused. Nesting: Minimal, with only one conditional; the else after raise is unnecessary. Clarity of intent: Names, annotations, and comments help, but a dict subclass that reads from __dict__ rather than dictionary entries is surprising and insufficiently explained. Code length: Concise overall, although overloads add visual complexity and a few blank lines are unnecessary. Action granularity: Each line generally performs one action. Reading flow: Methods follow a natural initialization, representation, and lookup sequence, but the unusual lookup behavior and missing type-variable definitions interrupt understanding.
Run 2
Code Structure: The class is logically organized into initialization, representation, attribute access, and lookup methods. Nesting: Mostly flat, with only a simple conditional; the else after raise is unnecessary. Clarity of intent: Method names, annotations, and comments clarify lookup behavior, but storing values in __dict__ rather than the inherited dictionary is surprising. _VT and _D are not defined in the snippet, and several imports are unused. Code length: Concise overall, though overloads add some visual weight. Action granularity: Each line generally performs one action. Reading flow: Methods follow a natural sequence, with consistent formatting; minor distractions include redundant parentheses, an extra blank line, and the unnecessary explicit None default in __dict__.get.
Run 3
Code Structure: Methods are logically grouped in a small class, although unused imports and undefined type variables (_VT and _D) make the snippet less self-contained. Nesting: Very shallow; the else after raising AttributeError is unnecessary. Clarity of intent: Method names, type annotations, and comments explain lookup behavior, but storing and retrieving values through __dict__ rather than the inherited dictionary is surprising, and the class docstring is vague. Code length: Mostly concise; overloads add justified typing detail, while redundant parentheses and the explicit None default in __dict__.get add minor clutter. Action granularity: Each statement performs a single clear action. Reading flow: Initialization, representation, attribute lookup, item lookup, and get follow a natural sequence, with consistent formatting and helpful spacing.